💾 Archived View for gemini.circumlunar.space › users › kraileth › neunix › eerie › 2012 › toolkits_i… captured on 2020-10-31 at 01:28:12. Gemini links have been rewritten to link to archived content
-=-=-=-=-=-=-
Here I'm republishing an old blog post of mine originally from October 2012. The article has been slightly improved.
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 article is meant for the latter. If you already have more than a rough idea about what toolkits are, save yourself some time and skip it.
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. So let's shed some light on this topic!
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 a one line example in _assembler_:
MOV AH,BX
This translates more or less to "put the value in 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. So it's not hard at all to tell what the following line does:
PRINT "Hello world!"
Yes, this code line for the language _basic_ just prints the well-known message to the screen. Basic is for the originally what is called an "interpreter language". This means that a set of commands is "translated" to 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++_.
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 existing advanced 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!
It's possible to append the library to your program executable - which is called _static linking_. This is obviously the safest way. The drawback however is that this increases the size of the executable (both in memory and on disk). In case of bigger projects which use a lot of libraries this is not such a good thing 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, too. Oh, 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 and works alike). Many toolkits do not support just one platform but are cross-platform TKs. This means that you could write a program based on some toolkit which could then run e.g. on Linux, MacOS and Windows without you having to care about how the particular system manages drawing graphics on the screen!
There are several toolkits available - some a bit lighter, some a lot heavier. Of course they work differently and offer a different set of functions, too. 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 various toolkits a little closer.