Writing GUI apps with the c language

 

Around the year 1992 there was a drastic event in the domain of software programming. The former well standardized Ansi C language has felt of fashion and was replaced by object oriented languages and scripting languages. Until today the fact itself is seldom mentioned and the reason why remain unclear.

A possible hypothesis is, that it has to do with the creation of GUI apps. From a technical perspective a GUI app can created with a library. In the easiest case the curses.h library allows to create an interactive text based application. More advanced software can be realized with GTK+ and the Win32 API. For reason of better understanding let us first focus on the curses.h library.

In contrast to the established Win32 API the curses.h library works out of the box in linux and windows as well and is much smaller than graphical libraries. So it is a great choice for programming a modern user centric application in the Ansi C language. The problem is, that even simple hello world apps written with curses.h are hard to understand and difficult to improve. not because of the library itself or because of the C language but because the subject is complicated.

The typical curses.h application contains of event handlers, keystroke events, multiple windows and object oriented style message parsing. Non of these techniques are created by the programmer itself but they are the logical consequence if the attempt is to create a GUI app on the text console.

If the console.h library is replaced by graphical oriented GUI libraries like GTK+ the complexity will grow further. Before the programmer can write a simple hello world app he has to read a dozens of books with each 1300 pages and even then many new problems will become visible. The situation in Windows and Mac OS is the same.

The only working advice to avoid the complexity of a GUI app is to dismiss GUI libraries at all. Without the curses.h libary only non interactive software can be created which are command oriented but not menu oriented. The average command line tool in Linux like the cat or the grep command doesn't need the curses.h or the gtk library but they can be programmed in the C language style before 1992.

So we can say that no a certain programming language or library has caused the increased complexity but the problems have increases since the year 1992 with the advent of text GUIs and graphical GUIs. Such a proram type is easier to use by the end user but it is very complicated to program it in software. There is not a single programming language or library available for this purpose but lots of different approaches were created over the years. And all of them are very complicated to use. Easy self claimed lightweight GUI toolkits like FLTK which are reduced to a minimum of features will need 100 MB to install the package and the documentation contains hundred of different methods and classes.

The advent of object oriented languages like C++, RAD Tools like Visual studio and JIT languages like C# wasn't a coincidence but it was the natural answer to the problem of creating GUI programs. It is not possible to write a modern GUI app the same way like a c program before the year 1992. In theory it is possible to write a GUI app with the c language, for example with the win32api or with the gtk.h library. BUt the resulting program will look the same like a complex C++ app which was scripted with additional languages. It seems, that the requirement itself to write a gui app is the cause of the complexity.

Programming in the classical ”before 1992” style is only possible in the case of command line programs. It seems, that the growing complexity after this years is caused by the objective to write the mentioned GUI apps.

This thesis would explain why the amount of GUI apps for Linux is low or even zero. The cause is that for creating a GUI app a huge amount of manpower and additional tools is needed. The best design decision is to avoid GUI apps at all and program only command line tools. Such piece of software can be written in ansi C,, will need a short amount of codelines and is easy to understand.

Let us give a simple example. A state of the art method to create a GUI app in Linux would be to use the Java language in combination with additional libraries and RAD tools for creating the buttons and widgets. The programmer has to install around 10 GB of software before he can create a simple hello world app which is doing nothing. This kind of workflow isn't a sign of failure but it is the best practice method. The cause is, that programming a GUI app is a complicated task and a complicated workflow with lots of layers and bloatware languages is the only way to handle it. Even if the user prefers a lightweight programming environment like Forth he will run into the same problems if he likes to create GUI applications.

The cause why software engineering before the year 1992 was so much easier was is because during this period GUI programs were not available. The typical program in that time was a MS-DOS game in single user mode or a unix command line tool without any interaction. Writing such pre-1992 apps is much easier. A normal c compiler is fits perfect to the problem.

What all the GUI apps in all operating systems have in common is, that they are large scale projects. No matter if the program was realized in C++, java or ansi C and no matter if it was programmed for Linux or Windows and every single case the average gui app will need 100 MB and more on the harddrive, contains of 100k and more lines of code and depends on lots of libraries.

Creating GUI apps in Linux

 A common question for programmer newbies is to ask which of the existing GUI frameworks is the most widespread used, or the easiest one to learn. Other users may ask which programming language might fits well for writing large scale GUI apps. The surprising situation is, that none of the existing libraries like Qt, tkinter or WXwidget can be recommended and all the mainstream languages like Python, Java and C++ are an antipattern to develop a GUI app.

With this forward it might be interesting to know what the preferred choice is in writing a GUI app. The working hypothesis is, that not a certain programming language is important but a certain GUI builder software. A gui builder is a WYSIWYG program which allows to drag and drop a GUI interface similar to painting an image, and then the code is generated by the program.

Let us take a closer look what very different software tools like MS-Access, Borland C++ Builder, code:blocks and WXglade have in common. In all these environments, the user isn't asked to write a single line of code, but he has menu with widgets like a button, a textfield and a combo box and then the tool knows how to write the code.

The reason why a gui builder is not optional but mandatory is because a GUI framework like Qt or any other one is a large scale library which contains of thousands of classes. It is not possible to use a small gui library. Even so called lightweight GUI libraries like FLTK will occupy around 4 MB on the hard drive and provides endless amount of options and parameters. The only way to master all the widget is an extra tool which is not working with sourcecode but with a graphical interface.

Let us take a closer look into a smaller but very powerful GUI builder which is wxglade. The amount of features is very low. The user sees in the left pane the list of widget and is asked to drag and drop them into the right pane. The interesting situation is, that in setting menu for the entire application it is possible to specify a concrete programming language:

The menu looks not very impressive,, it is only a dialogue box with the option for C++, python, Perl and Lisp. The interesting situation is, that at least the wxglade software knows how to convert a GUI window into runnable sourcecode.

Let us investigate what will happen after activating the "C++" option. The wxglade software is producing the .cpp and the .h files. Also it is written in the preface in the comment section how to compile the .cpp code into a binary file. The user has to enter the command into the terminal and gets the application. A simple example Hello world windows contains of a text widget and a button occupies around 164 kb in total and can be executed with "./MyApp". It is a normal C++ program written by a machine.

After creating the code, the human programmer is asked to improve the generated code. He can add some events or program the database backend by itself. The interesting situation is, that such a workflow is much easier than writing the app from scratch. The assumption is, that 100% of the C++ GUI apps are written in this programming style. In all the cases, the beginning is always a GUI Builder which produces some code, and this code is improved more or less by a human programmer into an application.

This pipeline makes sense because a simple form which contains of only 3 buttons and some widgets will result into a long class which has 200 lines of code. It is not possible or very complicated to write the code by hand only with a printed manual. This is only possible if the programmer knows already what a concrete programming language and a concrete GUI framework has to offer.

Perhaps it should be mentioned, that all the generated code from Wxglade is using the Wxwidget. Somebody may argue that wxwidget is not the best framework and this assumption is correct. But, suppose a different gui builder will use a different framework, for example Qt. Then the pipeline is the same. At first the programmer starts a GUI builder, the code is generated by the software and then the programmer improves the code a bit or more. So we can say the focus is always on a gui builder which stands in the center and a concrete programming language or a concrete GUI library is less important.



In case of GUI programming the question is not if C++ or Python is the better choice. And the question is not if Wxwidget or Qt makes sense. But the more serious question is, if Visual studio, wxglade or Eclipse is a here to stay. GUIs are developed with a certain GUI builder, the gui builder defines how the sourcecode will look like.

There is some sort of TIOBE Index for gui builder tools. Popular tools are visual studio, eclipse and android studio These programs are not used because of syntax highlighting or other text editor capabilities but the dominant reason why programmers are using Visual studio is because of the GUI builder functionality. It allows them to draw an application similar to draw a picture with a graphics program.

GUI builders
The most interesting feature of a GUI Builder is, that it interprets the world from a certain perspective. There is no need to decide for or against a programming language. For a gui builder the difference between C++ and is low, even both languages are very different from each other. The reason is that a gui builder doesn't asks the user to type in sourcecode, but the user has drag & drop widgets and press the "generate" button.

The reason why most GUI apps are developed for Windows is because the visual studio software is a mature one which is over 20 years old and its core component is the mentioned gui builder. Alternative tools like wxglade have less features and are less well documented.

The interesting situation with visual studio is that the software can be used to create C++ and C# code as well. So the question is not which of the languages is the better one, but the GUI builder works fine with both.

Even if GUI builders are highly important in software development they are seldom discussed in the literature. The assumption in the past was that it depends on the individual choice of a programmer if and which gui builder he prefers. Also the tools are nearly invisible in the final sourcecode, because what is available as sourcecode is written in a certain programming like C++ or java. So the assumption was, to focus on the language or maybe on the GUI library but not on the tool which is responsible for the code.



[1] https://visualstudiomagazine.com/articles/2017/08/15/ide-ranking.aspx

Creating GUI applications with wxpython

GUI Builder

The good news is, that all the tools are available in the Linux operating system to create powerful GUI programs. The disadvantage is, that the documentation is spreaded over many places and it is difficult to get an overview. The assumption is, that the reader is familiar with the Python programming language already and likes to create a full blow GUI desktop application. The tools which are needed are: wxpython library and the wxglade GUI builder.

The main problem with wxpython is, that the API contains endless amount of widgets and config parameters. The official API documentation is very large and reading all the material is not possible. The easier approach to create a window is a GUI builder. A GUI builder like wxglade allows the user to drag and drop the widgets into the frame. Such a gui builder is a must have tool, because otherwise the user has to enter the commands by hand into a programming editor. And here is the problem located which is visible for GUI programming in general. How does the user know which widget is created is created with which command? Right, he can't know because it is written in the documentation. But, searching for the correct statement in the docs takes time.

Let me give an example. Suppose the user likes to draw a text entry field. In the wxpython framework it is created with wx.TextCtrl(parameters). The reason why is because the API defines how to create such an element. Such command has nothing to do with programming in general but it is about using a certain GUI framework. The problem is that each GUI framework like tkinter wxwidget or Qt is using a different sort of commands. In addition, the parameterlist for all the commands is endless.

So the only option for the newbie is to the mentioned wxglade GUI builder. Here the user doesn't know the detail, but draws a window similar to create a PNG image in gimp. The GUI builder creates the code automatically which can be copied and pasted into the own application. A typical criticism against gui builders is that if the layout has changed the code has to updated manually. This concern is correct. It doesn't make sense to use a GUI builder for creating the code direct, but the GUI builder is a learning tool which allows to understand which commands are needed.

The user reads the automatically created code, and recognizes, that a certain widget was created with certain commands. This allows to get a faster overview over a widget. So the gui builder is the starting point to search for the details in the wxpython API documentation.

MVC principle

Another powerful concept to simplify the creation of a GUI app is the model view controller principle. MVC means to split a window into three different classes for the database backend, the layout and the events in the window. The layout contains of commands for creating the widgets. These commands are created with a gui builder or typed in manually. If the user is prressing on the buttons nothing will happen.

The event handling is done in another class which is the controller class. It is listen to the events and changes values into the form. If the action is more complicated the controller is using the backend class for additional processing.

Suppose the GUI app consists of 3 windows. Then the overall amount of classes is 9:

window1view

window1controller

window1model

window2view

window2controller

window2model

window3view

window3controller

window3model

 

References

[1] wxPython tutorial https://zetcode.com/wxpython/

[2] wxPython API Documentation https://docs.wxpython.org

[3] Youtube wxglade

GUI development with Linux

The most convenient way in creating graphical applications for a Linux desktop is the Python Tkinter framework. In around 50 lines of code, it's possible to create a hello world window which includes a button and a text entry widget. The interesting fact is, that potential alternatives to that technology are much more complicated.

A possible alternative would be to use Python and GTK to create a native Linux desktop GUI app. The problem with gtk under Python is, that the amount of documentation is low, i have tried out to create a simple hello world gui and failed. The problem is not completely new because the combination of C++ and GTK is also hard to master. The reason why is hard to explain, but what is for sure is, that python+tkinter is much easier to master.

Let us take a look what Windows programmers are doing. The normal way in creating a GUI app goes over the C# language which comes with a strong GUI library. Creating a C# GUI app in Windows is as easy as with tkinter in Python. The difference is, that a C# program can be used for productive code, while Python is some kind of prototyping language.

The hypothesis is, that right now, no good GUI frameworks are available for Linux. In the normal C++ language no GUI library is available and using GTK is too complicated. It seems, that from a os development side it's complicated to create and document a GUI framework which is used by normal programmers. A naive approach would be to use the C# language in Linux as well, but unfortunately, the forms library will work only in Windows environments.

The reason why Linux desktop are not equipped with a more elaborated GTK framework is simple. It's part of the Anti-RHEL conspiracy. Microsoft, Adobe and all the major computer journalists are boycotting the Linux ecosystem and the small Red Hat company is not strong enough to build it's own GUI framework. THe problem is, that GUI toolkits are patent protected and it's not allowed to develop an easy to use framework from scratch. In theory, Red Hat can develop a more elaborated GTK toolkit which is easy to use from Python and C++ but as a consequence Microsoft would start a legal conflict against Linux and the result is, that no Linux operating system at all will be available anymore.

The simple advice for programers is to stay within the Microsoft environment. It's the more easy to use operating system for GUI development. C# under Windows can be seen as the best practice method in programming a GUI interface. As a consequence many native Windows applications were developed by the programmers while under Linux only textual programs are available.

Pyglet hello world program

According to different internet websites, a potential alternative for the pygame library is the pyglet framework. It's a bit harder to use, the number of tutorials is lower but the performance is much better. In pygame, the general problem is, that even a slow framerate results into an application which consumes many CPU ressources. Pyglet allows similar to a C program direct access to the OpenGL interface which improves the performance. Additionally, there is a feature available called batch, which is useful for particle simulation in which hundreds of verticies are drawn at the same time.

It's unsure, if pyglet can replace the famous pygame library. Because it's very new, and the information are spread over different stackoverflow entries. For testing out the capabilities, a small hello world program make sense, which draws a line, a sprite and asks for keyboard input. From the performance side, it's much better than pygame. The window consums nearly zero CPU ressources, it's on the same level like a game written in fast C++ with the SFML library. A short look into the sourcecode shows, that pyglet is a bit tricky to use. The first thing which is important is to inherit a window, and secondly, the manipulation of the colors is complicated too. The hope is, that in larger programs, it will become easier to use, because the drawing primitives can be capsuled in subfunctions. What we can say for sure, is that the program written in Python is much easier to write, than the same App written in C++, Java or C.

#!/usr/bin/env python3
import pyglet
from pyglet.window import key

class GameWindow(pyglet.window.Window):
  def __init__(self, *args, **kwargs):
    super().__init__(*args, **kwargs)
    self.pos=(200,200)
    self.angle=0
    self.movement=20
    imagetrain = pyglet.resource.image('locomotive.png')
    self.spritetrain = pyglet.sprite.Sprite(imagetrain)
    self.label = pyglet.text.Label('Hello, world',x=100,y=100,color=(100,100,255,255))
  def on_mouse_press(self, x, y, button, modifiers):
    pass
  def on_mouse_release(self, x, y, button, modifiers):
    pass
  def on_mouse_motion(self, x, y, dx, dy):
    pass
    #print("move mouse")
  def on_key_press(self, symbol, modifiers):
    #print("key was pressed",symbol)
    if symbol == key.A: self.angle-=10
    elif symbol == key.B: self.angle+=10
    elif symbol == key.ENTER: pass
    elif symbol == key.LEFT: 
      self.pos=(self.pos[0]-self.movement,self.pos[1])
    elif symbol == key.RIGHT: 
      self.pos=(self.pos[0]+self.movement,self.pos[1])
    elif symbol == key.UP: 
      self.pos=(self.pos[0],self.pos[1]+self.movement)
    elif symbol == key.DOWN: 
      self.pos=(self.pos[0],self.pos[1]-self.movement)
    self.spritetrain.update(x=self.pos[0],y=self.pos[1],rotation=self.angle)
  def update(self, dt):
    pass
    
  def on_draw(self):
    self.clear()  
    pyglet.gl.glClearColor(1,1,1,1)
    pyglet.graphics.draw(2,pyglet.gl.GL_LINES,
      ('v2i', (10, 15, 130, 135)),
      ('c3B', (100,100,255)*2), # one color per vertex
    )
    self.spritetrain.draw()
    self.label.draw() 

if __name__ == "__main__":
  window = GameWindow(600, 400, "pyglet",resizable=False)
  pyglet.clock.schedule_interval(window.update, 1/30.0)
  pyglet.app.run() 

Update

In a second version of the program, a dedicated class for the physics state was created. This simplified the programming a bit. The remaining commands for drawing the lines and the sprites will become easier, because once the code is written, it will draw all the elements to the screen.

Secondly, it was measured the exact cpu consumption. For 100 frames per second, the GUI app needs 15% of the totai CPU.

ps -p 31339 -o %cpu,%mem,cmd
%CPU %MEM CMD
15.1  1.3 python3 1.py

If the framerate is increased to 200 fps, the cpu consumption is 18%. It's important to know, that the only objects on the screen, are one sprite, one line and a small “hello world” text. It seems, that Python programs in general are running slow? No, that is not the case. Because a program written in high speed C++ with the SFML library has the same performance problems. It seems, that the requirements of updating the screen 200 times per second is too much for computers in general. No matter in which programming language the code was written.

Creating a GUI with C++, gtkmm and glade

The first impression for the beginner is, that C++ is very complicated if the aim is to create GUI application. Other languages like C# and Java seems to be more comfortable. The major problem is not the language itself, but it is a lack of documentation. I've searched a bit in the internet to find a good documention, but it seems very complicated. Most tutorials about gtkmm are about manually creating the buttons in the sourcecode which is outdated. What today's programmers want is a GUI tool like glade. But how to use glade together with C++? That is unclear, I didn't find a good documentation for that problem, but it seems, that the C community is better informed. Under the URL https://prognotes.net/2015/06/gtk-3-c-program-using-glade-3/ is a nice tutorial given which shows a hello world example which contains of C sourcecode together with the glade editor. I've modified the code a bit for C++ needs and here is my hello world example:

// Glade gui with gtkmm
// g++ -std=c++14 `pkg-config --cflags --libs gtkmm-3.0`main.cpp
// https://prognotes.net/2015/06/gtk-3-c-program-using-glade-3/

#include iostream
#include gtkmm.h
int main(int argc, char *argv[])
{ 
  gtk_init(&argc, &argv);
  GtkBuilder *builder = gtk_builder_new(); 
  gtk_builder_add_from_file (builder, "gui.glade", NULL);  
  GtkWidget *window = GTK_WIDGET(gtk_builder_get_object(builder, "mainwindow")); // from XML file
  gtk_builder_connect_signals(builder, NULL);
  g_object_unref(builder);
  gtk_widget_show(window);                
  gtk_main();

  return 0; 
}

The basic idea is to use the Glade gui tool for drag and drop the window and save the XML file as “gui.glade”. Then in the C++ program this XML gets loaded and become visible on the screen. It seems to be a common idea, but it is very hard to find tutorials for such a simple task.

Like I mentioned above in the introduction, the problem is not C++, glade or gtkmm. With these tools everything is fine. The resulting “a.out” application works stable, and the ecosystem is mature. The problem is a lack of documentation. Most programmers are only familiar with Windows GUI system, and here C# replaced the previous C++ entirely. While in contrast under Linux, most developers are only programming textbased-commandline tools and have no need for a nice looking GUI.

I strongly believe, that this will not be the last tutorial for combining glade with C++. Perhaps in the future some extension become possible, for example a more advanced GUI application which is more then a simple hello world example. But for this time, this tutorial is over.

First look on glade

Programming a GUI application in Linux is hard. There are lots of standards available (gtk+, Qt, mono develop, Python Window) and it is unclear which of them is a here to stay. The hypothesis is, that the combination of: C++, gtkmm and the Glade GUI designer is the best practice method to develop own apps easily. But I'm not sure how this works in detail. Today, I only want to take an introductionary look into the Glade GUI designer and evaluate what is possible with the tool.

The installation is easy. A simple “dnf install glade” is enough to fetch the 3 MB size file onto the local Fedora machine. After starting the program the user sees a screen like this one:

In the menu, the user can drag&drop his GUI application which works like in a painting program. And he can execute the preview function to show, how the GUI will look like.

But, there is one part, which i haven't figured out right now. How to use the GUI in C++ program. As far as i know, the file is stored in the working directory with the “.glade” extension. It is an XML formatted file which can be used inside Python, C or C++ apps.

But the details are unclear right now. Nevertheless, the glade tool itself, seems very powerful. The above example GUI-window was created in under 5 minutes with simple point&click mouse movements. The user selects first the window type, specify a grid and moves them the elements like a menu bar, the textfield and the button into the window. Then he can give names for activation events for example “pressbutton”. These event should be parsed later in the C++ program.