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.
'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 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.