Current Topic: Aside from the overwhelming complexity that comes with using the various Linux GUI tool-kits there is an equally unacceptable set of dependencies dragged along with them. I write simple programs. Not 'Goliaths'. I do not require the bulk or the extreme case handling.
I Decided I Needed A Basic Set Of GUI Classes So I Wrote A Library...
After a couple of simple X11 examples I wrote it became obvious the development would be stalled without some way to communicate with these programs. I needed dialogs and menus and I didn't like the various tool-kits or their individual dependencies that Linux had to offer. Hmm. I had to make a decision. Since the sole purpose of these programs is merely an intellectual exercise anyway I decided to write a set of utility-window classes to supply basic I/O (keyboard, mouse) for my programs to use.
Why did I have to do this...
One of the most surprising Linux downfalls to me are the thin Window-Manager interfaces. I would have hoped for at least recognition of basic window-types. And maybe style elements. Even just Atom definitions would have been sufficient to help offload some of the burden which various toolkits use to 'theme' or 'skin' themselves. With a little bit of additional Window Manager definition (consistency) I see a better division between layers that doesn't disenfranchise the 'thin' client. Like Me. Simplifying the interfaces also simplifies the abstractions (layers) encouraging the endless variety that toolkits offer while still providing 'easy' access to lower layers where the additional management may be worth a simple programs extra effort. Maybe to be more 'Binary Compatible'. i.e... I would expect all my programs to be binary compatible across distributions. As long as any Window Manager is running.
The trouble I have though is that without carrying the bulk of a toolkit I don't have access to it's theme engine. If the style attributes, as well as the type attribute, are instead defined (Atoms) at the Window Manager level then they are 'globally' available to every 'windowed' environment. And they are extendable.
Oh Well! I Guess Software Is Still A Young Science...
What I am attempting to create, as an exercise, is a set of consistent interfaces for common window types. Each 'common' Window is assigned a known type Atom. Along with associating each window 'type' with various attributes (properties) defined as Atoms. At the Window Manager level I hope to eventually define properties used for global styling (theme). This mechanism will allow me to 'share' the library, and theme, across multiple applications while still maintaining dynamic re-theming or even custom application level themes (override).
As of now... The library has minimal functionality. It also suffers from a lack of cohesion. Also I have not yet implemented themes. Currently all style attributes are defined with 'default' values and may not even be settable at the application level.
To be honest... This all started because I wanted a menu for my Oscilloscope project. Maybe I'm getting a little carried away.
Currently The Library Supports:
Implementation Philosophy.
Each library interface class (window) will provide methods to create, destroy, identify and control and query any state, flag or attribute. Each library class will provide default methods for Xlib basic message requests. This offloads the burden of display processing and user input detection to the class. State change events are relayed to a parent window as 'Client' messages for processing. It is therefore up to the parent to decide the fate of the message as well as make any changes to the state of the child.
This level of interface however requires additional management for the main application Window. All child (Window) messages will be received by the application framework and must be relayed to an appropriate object (class) of which the frame is responsible for resolving.
Yeah! That seems like a lot of work though. Well... Maybe for a spreadsheet program But for a simple program that needs only a few buttons and a menu and maybe a couple of output-only windows the burden is surprisingly minimal. You see... This is where toolkits pissed me off. For all my apps, small as they might be, I Do Not Want To Have To Chose Which Toolkit To Support. I Do Not Care About Widgets. I just want a simple way to gather input for small utility applications.
Besides... This is what abstraction layers (interfaces) are useful for (simplifying).
5479
