X11 Work Bench Toolkit 1.0
Welcome to the main page for the X11workbench Toolkit documentation. As you will no doubt see, this was generated using Doxygen, and the provided 'doxy.txt' file, which you are welcome to customize to any extent you see fit.
The X11workbench Toolkit is my response to the inadequacies, difficulty in learning, and general overcomplexity of X11 GUI development. Going back to my roots in OS/2 and Windows programming, I have tried to take what I believe is the best (and simplest) of THAT world and create a toolkit that looks, well, a LOT like what I came from, taylored specifically to the world of X11.
The main goal is to produce a toolkit that can be copied and pasted into just about any GUI project, and then used as-is to provide straightforward no-nonsense windows with easily recognizable features, without carrying around a boatload of extra baggage commonly found in large scale toolkits.
Let's face it, X11 is DIFFICULT to code for natively. That is, it's difficult to code for unlessyou don't want to do anything besides creating a simple window with nothing in it. The use of a decent toolkit can shave YEARS off of a project. However, if the toolkit causes load times to become IRRITATING, or use up way too many resources on the computer, or put too many dependency requirements on developers (until it becomes nightmare fuel), it can ultimately lead to frustration and disappointment.
Hence, THIS toolkit was made as an alternative to the "boatload of garbage" that so often ends up being shoved into a 'monolithic toolkit' (or API) that just has to fill every possible set of shoes ever thought up. It is common to list a projects features in the design phase, such that the most important features are ranked according to importance, in a pareto analysis. And a common principle in this kind of pareto analysis is that the first large chunk of functionality can be taken care of in a small chunk of time with a small chunk of resources. The remaining functionality (that which pleases the widest possible audience) will typically take up SIGNIFICANTLY more time and resources to implement. It's sometimes called a 70/30 rule or an 80/20 rule, implying that the first 70% or 80% of functionality can be done in 30% or 20% of the time. The remaining functionality (a much smaller percentage) consumes an inordinately LARGE amount of the time. So I will only focus on the 70% or 80% [when compared to other toolkits] for my own toolkit.
After all, if you try to please EVERYBODY by providing EVERY possible functionality they might need, you'll end up with a gigantic monolithic pile of wastefulness that requires way too many resources to write, run, and maintain. And typically it is CONSTANTLY being updated to the point of insanity. The only reasonable way to make things work well in a 'lightweight' sense, with at least SOME stability, is to pick the key features that MOST people will need (the 70%), plus those that are needed to 'glue' it all together, and ONLY address those. If the end users or developers want all that other stuff, they are free to use a monolithic, all-encompassing toolkit to do it. Otherwise, if you want a lean and mean application with a lightweight toolkit that loads fast, runs fast, and doesn't take a whole lot of effort to create an application with, you'll probably want to use the X11workbench Toolkit.
There are many who ALWAYS say 'do not re-invent the wheel'. But auto makers do that EVERY YEAR. And this wheel needed to be re-invented, so I DID IT. It took a while, and nobody came up with anything better during the several YEARS I have been working on this (at least as far as I know).
So, if you were looking for a monolithic toolkit that supports every possible feature on the planet, then you'll want Qt or GTK or similar. If you prefer C++ objects you might consider Motif or wxWidgets. Otherwise, have fun with a very simple, yet very effective C language toolkit, aka the X11workbench Toolkit. You're welcome.