Widgets

Well, having considered X and now window managers, its time to look at widgets. What are they? Well let's consider the fact that, if you were a programmer (and possible some of you are); to create a nice radio button on the screen for a user to press, or possibly to place a scroll-bar to allow the user to scroll up/down, left or right, using the straight X libraries (Xlib) is a really complex difficult task. Why? Well simply because, as we said, X is not really that concerned with how your application "looks or works". It's job is merely to display - this is starting to sound like a typical government department!!!

Instead however, there were widgets defined. These were simply a set of API (application programmer interface) libraries that the programmer could call to "place a scrollbar here", or "place a minimize button there". These are the widgets - widgets are the scrollbars, the radio buttons, the check-boxes, Etc.

Now the early widget libraries were Athena (a really clunky GUI interface) and Motif - a much slicker (although not free) interface. To see what the Athena widgets look like, try starting xcalc or xfontsel. Not nice hey! Now you can understand why Motif gained popularity in the 1980's and 1990's. BUT, it was not free - something that no self-respecting Open Source person would tolerate.

So developers started work on alternative toolkits. Enter the Gtk - or the GIMP toolkit. Gtk is well known in Open Source circles today and is the underlying toolkit in the development of Gnome. To be fair to those KDE enthusiasts, KDE is built upon an equally competent toolkit called the Qt. The open-ness of Qt is a point of some fierce debate, but this is not the forum. Finally, in response to the Motif toolkit, some enthusiasts developed LessTif - an obvious pun on the Motif name. LessTif was release free and packed a mean little punch in what is could achieve. Hence, LessTif is being used in a good number of window managers.

So here we are:

We have X which interacts with the hardware. A window manager which provides us the functionality for managing our screen real-estate, and toolkits which allow our clients to have the nifty features we expect in a GUI environment. However, perhaps we are running Netscape Navigator, which used the Motif toolkit, xcalc which used Athena, and other clients which use Qt and Gtk. Many different toolkits equals many different toolkits clogging up our memory. Not only that, but the look and feel of one is different from the look and feel of the next. What are we going to do Bob? Enter the final component of our X environment: the desktop environment.

The desktop environment provides the consistency we as users expect from our window environment. That all similar buttons work the same, that the windows all look and feel similar, that there is a file manager to manage our directories. These are all functions of the desktop environment and a place to put our useful applications like a clock. An analogy of the taskbar in Windows springs to mind here. This is something that Microsoft got right from day 1 and we see where it has got them today. However, MacOS got it right before that - and just to lend counterweight to my argument - it got them less far.

Why all this complexity in the UNIX/Linux environment? Simply to provide flexibility and functionality. These are two words that are not known in those environments mentioned earlier. If you don't like the way MS Windows looks or works, how much can you do about that? Similarly for MacOS. These layers of abstraction allow us to run an environment that we want - not that we are told we will have. Unfortunately this is all rather confusing for the user and possibly a little daunting for the newbie. But, that how it is.