The topic of this post is GUI (Graphical User Interface) toolkits. As I wrote before, the EERIE blog is for both Linux veterans and novice users. This entry is meant for the later. If you already have more than a rough idea about what toolkits are, save yourself some time and skip it.
Why to give thought about toolkits?
The importance of the decision which desktop environment to use is pretty obvious. In case of GUI toolkits this is less self-explanatory. However deciding on the right TK is a crucial issue when planing a new distribution. But what are toolkits and what do they do?
While this is not too complicated a subject, it can also be a bit confusing. Especially since there are several commonly used terms which mean the same thing and also some often used in a semi-wrong way that can easily lead to misunderstandings. But let’s shed some light on this topic!
Low-level and high-level programming
With any pc it’s the CPU that can execute a number of instructions. While the set of special instructions grew bigger and bigger (think of MMX, SSE, etc.) over time, it’s generally a big hassle to create more complex programs entirely by doing low-level programming.
Here’s one example in Assembler:
This line translates more or less to “put the value of register AH into register BX“. It’s not hard to imagine that coding like that is complicated, tedious and not very intuitive at all (the programmer has to keep an overview of what is in which register in our example).
For this very reason high-level programming languages exist: it’s far easier to do complex tasks in a more abstract way that is closer to what the human brain works like. It’s not hard at all to tell what the following line does:
PRINT "Hello world!"
Yes, this code fit for the language Basic just prints the well-known message to the screen. Basic is for the main part an “interpreter language”. This means that a set of commands is “translated” into machine code by the interpreter. While Basic provides a fine example here, it’s a little too simple to be fit for serious programming today. There are many high-level languages available, probably the most common being C and C++.
Source code, compilers & libraries
If a programmer wants to create a new program, he or she writes the source code (all the commands which produce the program in the end) for it in his or her prefered language. Afterwards the source code gets compiled (and linked) and the result is an executable program file.
While all high-level languages offer a certain set of commands, it would still be very cumbersome if all programmers had to stick to just these. It absolutely makes sense not to re-invent the wheel each and every time but to simply use some advance routines. Those are often provided by various libraries which are not by themselves programs for the end-user but in fact act like collections of functions which can be called by other programs.
Printing some string on the screen is a typical example. Almost every program needs to have this ability. Every programmer could write his or her own routines or just use an external one to do it. In the later case the programmer also has to decide how to ensure that his program can relay on the external resources. There are two ways to do this!
Static and dynamic linking
It’s possible to append the library to your program executable – this is called static linking. This is obviously the safest way. The drawback however is that this increases the size of the executable. In case of bigger projects which use a lot of libraries this is not a good idea at all. In addition this may be a wast of disk space if you have several programs on your computer which use the same library and each one has it statically linked!
The other possibility is to use dynamic linking. In this case the external resource stays external: the program relays on a library that needs to be installed on your computer. These libraries are called *.so (shared object) on Linux systems and *.dll (dynamic link library) on Windows. To use these is much more efficient in terms of space. However it can be a nuisance if a program depends on a lot of libraries and it can also be a problem if one program relays on an old version of a library and doesn’t work with a newer one while another program needs the latest one…
A GUI toolkit, also known as widget toolkit or sometimes widget library is a special kind of library. Their purpose is to provide a set of “widgets” (like a button for example) which other programs can use. This ensures that any e.g. a button drawn by any application using the same TK follows the same style (i.e. looks alike). Many toolkits do not just support one platform but are cross-platform TKs. This means that you could write a program based on sometoolkit which could then run e.g. on Linux, MacOS and Windows without having to care about how the particular system manages drawing graphics on the screen!
However there are several toolkits available – some a bit lighter, some a lot heavier. Of course they work differently and offer a different function volume. But those things will be discussed at a later time.
The next post will be about something really neat that I discovered recently. I won’t spoil it yet, but it’s something that probably nobody would ever expect. I just have to write about it! After that we’re going to examine the toolkits a little closer.