home / libGx

LibGx design requirements and goals

The toolkit should be flexible enough that it does not stipulate how main() is written.  Do you want the toolkit to handle the event loop? ok.  Do you want to write your own select() in main? ok. Do you want multiple threads? ok. (but keep all libGx calls in one thread, or handle locking yourself.)  I have used libGx in several quasi real-time environments by slightly throttling XEvents into the gui.

The toolkit should not hide X11 from the developer or the application.  The toolkit should greatly simplify writing an X11 application, but not be so expansive that the developer is not aware that a X11 app is being written.

The toolkit should be very, very fast and have low memory requirements.

The toolkit should be lightweight enough that it can be compiled into or at least bundled with the application, to guarantee it can work effortlessly on different systems, and not be reliant on the existence of certain libraries or versions thereof.

The toolkit should be able to be used by commercial and free software without restrictions.

Rather than encapsulating Xlib and then extending it with a widget library, libGx is a C++ GUI component library only, thus leaving Xlib exposed and preventing another layer of function calls for drawing.

The goal of this library (beyond creating a usable library) was was to explore the creation of a display independent, look&feel independent, API for developing applications without moving to a display independent drawing API. More specifically I wanted to find out how how minimalistic the widget and geometry management APIs can be, yet have them still provide enough features for most applications.

Geometry control is implemented by a relatively simple mix of geometry placement rules, specialized placement widgets, and plug in geometry controls for widgets. This system replaces complex inter-widget communication by a little forethought by application builders. The ultimate goal is an application that can display itself correctly over a wide range of display resolutions while maintaining the capability of using different widget look&feels (i.e. posses limited automatic compensation for variable object pixel sizes).

At one point I treated libGx as a prototype for a server-side widget API.  I now suspect that it does not make sense to move to server side widgets until after paper resolution displays become widely available and software developers have figured out how to fully utilize the capability of GPUs in a desktop environment. This will take a few years.

My take on developing gui code is that a good 'deep' application will end up being embedded into the OS and or desktop infrastructure too much to be easily portable at the gui toolkit level.  In such an application, platform independent abstractions will have to be maintained deeper within the application code (A gui and platform base class for example).

I do not think that the X desktop will ever converge to a single widget library.  There are too many different programming styles and ideas about the way that things should be done.  I don't think that having slightly different interface styles between applications detracts from the usability of the desktop for the typical *nix power user.  The idea of wrappering a 'C' widget library that can be used by everything seems tacky and adds an incredible amount of code/complexity/overhead for something that should be so simple and transparent.

LibGx History

'Way back' in the mid '90's when I started developing Linux code using C++, I had the need for a widget library.  Among other solutions  I looked at wrappering Lesstif (far too incomplete),  Qt (not LGPL and required a tacky pre-compilation pass), amulet, V and others.  I ended up picking several ideas from projects at the time and developing something new.   I have written a _lot_ of code that uses libGx since then.

LibGx hopefully pulls the best ideas from several sources.  LibGx began as a rewrite of the grafix library, but due to its license, I eventually started from a clean directory and re-wrote everything, so no code or names are shared. Grafix is neat because of its simple object hierarchy. Today after numerous rewrites and changes to libGx, only the ideas of a "window" class and a hash table of object pointers from window id's remain from grafix.

LibGx's callback mechanism (libCb) was developed based on a component of Brandon Van Every's Free3d project.  If I remember correctly (its been a few years) I removed the need to use wrappering constructor functions  to instantiate function objects.  

LibGx Future Changes

LibGx is not fully complete, but it works well enough that I have not made extensive changes to it in a few years. As the need arises, bugs will be fixed and it will be developed further. Some of my original design choices (no internationalization, heavy use of C strings) look outdated now and I am certainly willing to see changes made in these areas.

Some areas in particular I need to fix are that the dock-able button-bars don't dock/undock correctly, keyboard traversal is iffy, and I think libGx should wrapper LibTmr rather than using it directly so that the platform's or application's native timing facility can be substituted for LibTmr if the developer so chooses.