Fred's Home Page

Micro Window-Gadgets

[ news | download | about | technical | screenshots | gadgets | properties ]

News

Recent UWG happenings:

• 03/12/2006 released version 0.2.0
• 25/08/2006 released version 0.1.6
• 26/06/2006 released version 0.1.5
• 26/02/2006 released version 0.1.4
• 01/06/2005 released version 0.1.3 (still under development)
• 25/07/2004 released version 0.1.2 (still early days)
• 12/07/2004 released version 0.1.1 (in extreme development)

About

Micro WG is a C `version' of WG. In general, UWG is somewhat more light-weight than WG. Firstly because it's written in C and not C++. Secondly because it does not yet provide all the features of WG. Also, it should be significantly easier to `connect' UWG to KRoC.

Why UWG ? It's now the case that there are many `widget libraries' for programmers to choose from. The traditional X11 widget libraries (X Toolkit Intrinsics), GTK, QT, Motif, wxWindows, TK, etc.. GTK and QT are probably the most common for an average user's desktop system -- as the graphics libraries of Gnome and KDE respectively. C++, used by WG, provides a largely type-safe environment for gadget programming -- i.e. the structure/nature of gadgets fit neatly into the C++ type (class) heirarchy. However, C++ ultimately suffers from the same problems as some other `object-orientated' languages -- namely leaky encapsulation. When writing WG, some of the limitations (maybe features) of C++ caused significant problems, particularly in the function-pointer department. Object-orientation is a fine model for data, but it does not work well when `bolted-on' to sequential languages -- C++ and Java in particular. Forcing a sequential flow-of-control through something that we tried to break into objects only leads to problems. E.g. when executing inside the method of one object, is it safe to delete another object ? -- well, only if that other object wasn't involved (and still is involved) in the flow-of-control. And this you cannot easily tell. Furthermore, in many cases, `delete' may be substituted for any object interaction (method-call).

Also, a lot of modern GUI toolkits seem unnecessarily bloated. C++ (and other `frilly' languages) can be blamed for some of this, but not all of it. WG isn't bloated yet, but it's not far off. UWG is therefore an attempt at a lightweight (size and speed) gadget toolkit for X11, programmed in C.

Download and Installation

Here are the downloads for UWG. At the moment, the distribution is fairly basic, but it should work. Prior to version 0.1.6, UWG didn't really install itself anywhere. Now it will attempt to park itself in the right places.

• uwg-0.2.0.tar.gz source tarball (435.1k) [MD5: cecbe7b042c2cd73069a3dbfda02aa38]
• ubuildinit-0.2.0.tar.gz source tarball (166.6k) [MD5: e08a0867bab7a99b279a7fe649e7ea9b]
• uwg-examples-0.2.0.tar.gz source tarball (263.4k) [MD5: 8cd3bdf5e3023db93171d3c36358ed58]

• uwg_prefs preferences file (for UWG 0.2.0 and later), edit as desired and copy to ~/.uwg_prefs (default included in distribution)

UWG, by default, will configure itself for a regular installation -- i.e. it expects to be installed (this is because the generated uwg_config.h contains the locations of files which other packages can scan for). You can park it somewhere else in the usual way, for example:

    bash:~/uwg-0.2.0/$ ./configure --prefix=/home/fred/uwg
    ...  configure output
    bash:~/uwg-0.2.0/$ make install

Then unpack the other packages (ubuildinit, uwg-examples), configure with:

    bash:~/ubuildinit-0.2.0/$ ./configure --prefix=/home/fred/uwg \
        --with-uwg-config=/home/fred/uwg/include/uwg
    ...  configure output
    bash:~/ubuildinit-0.2.0/$ make install

    bash:~/uwg-examples-0.2.0/$ ./configure --with-uwg-config=/home/fred/uwg/include/uwg
    ...  configure output
    bash:~/uwg-examples-0.2.0/$ make

Technical

One slight disadvantage to not using C++ is that the code gets uglier. The gadget types are C structures that contain the gadget's state, along with various function-pointers for performing actions, etc. Instead of the multitude of `get/set' methods, gadgets have single `get' and `set' methods, that use a `uwg_prop_t' parameter and var-args. As part of the gadget's state is a `UWGVisual' pointer. This is a generic visual gadget that replaces `WGVisual' in WG. Gadget callbacks are now wrapped up in a separate structure, rather than being part of the gadget structure, e.g. `UWGButtonCB'. Gadgets maintain a pointer to their callbacks.

The various event callbacks (e.g. `xc_paint') are still separate. However, since these are now function-pointers, gadgets can override the default behaviours of other gadgets -- e.g. the UWGVDE gadget does this to control interactions with its children. As far as looking after children goes, WG used to maintain the visual heirarchy of gadgets. It no longer does this. Gadgets that need to be aware of their children can use the `xc_addchild' and `xc_delchild' callbacks, invoked by gadgets when created on them. To maintain a complete visual heirarchy, the `xc_{add,del}child' callbacks can be re-assigned as new gadgets are created; the intervening code can then decide whether to keep the event for itself, or pass it on to the original gadget (if it has an appropriate handler).

The central-point of UWG is the `UWGXContext' virtual gadget. This abstracts a connection to an X11 server, used by the various gadgets and the application. Unlike some other gadget toolkits, a UWG application can connect to many X servers -- if desired. This might be useful for multi-client applications -- e.g. a simple multi-user game. However, the first aim of UWG is to provide a toolkit -- application `help' is secondary, but still considered.

The use of C and functions with variable numbers of arguments creates a number of potential pitfalls -- such as calling a var-args function with incorrect parameters, that will most likely (and currently) result in a run-time error or undefined behaviour. The gadgets themselves will perform some checks, but mostly it is down to correct application programming. E.g. an attempt to set a gadget property that doesn't exist is benign, but an attempt to set a property using a different type than was expected will cause serious problems.

Fortunately, and much like WG, it is not expected that programmers write the code for creating and initialising (visual) interfaces themselves. WG uses a tool called `buildinit' to transform HPD (heirarchial program description) files into C++ code that creates (and destroys) whole interfaces -- typically top-level windows. UWG posesses a similar tool, but one that converts XHPD files into C code. XHPD files are `XML heirarchial program description' files, that use XML to describe the interface. A related program, RAPP (remote applications), can already process these XHPD files usefully. Rather than generating code, RAPP dynamically creates the described interface.

The follow shows an example of XHPD, that describes a simple button:

    <gadget type="UWGBitBtn" name="button2">
        <property name="geometry" value="100,32,144,40" />
        <property name="hint" value="this is a hint!" />
        <property name="font" value="fixed" />
        <property name="caption" value="more click!" />
        <property name="style" value="popup" />
        <property name="img-up" value="/usr/include/X11/pixmaps/screen.xpm" />
        <property set="cpref" />

        <action name="on_click">
            <property name="shadow" />
            <property source="mylabel" name="font" />
        </action>
    </gadget>

This particular example is designed for RAPP -- where the contents of the `<action>' tag are properties to be reported with the event. For producing C code to create interfaces, more useful would be application code. For example:

    <action name="on_click">
        <![CDATA[
            printf ("The button (%s) was clicked!\n", button2->visual->idstr);
        ]]>
    </action>

<update> and <command> blocks are interpreted by both "ubuildinit" and RAPP. For example:

    <action name="on_create">
        <command name="add_item">
	    <arg value="UWGPanel" />
	</command>
    </action>

Screenshots

Here are some screenshots of UWG. Note that more will appear as development progresses..

UWG testapp screenshot	another (ubuildinit-generated) XHPD example	initial VDE efforts in action, XHPD file

Beginnings of UWGBuilder, a UWG version of WGBuilder	A vaguely functional UWGBuilder	Beginnings of a remake of gametest

Gadgets

Here is the current list of supported gadgets. There is an on-going process of converting WG gadgets into UWG gadgets -- it's not too difficult, but is quite time consuming. Gadgets will be added to this list as they are dealt with. See the WG gadget-list for `missing' content.

Properties

Gadgets typically have `get_property' and `set_property' ``methods'' (function-pointers). These take a property constant and some values. `get_property' always takes a pointer to the type that `set_property' takes -- and if a pointer is `returned', it is the gadget's own, not a copy (e.g. string properties).

Here is the current list of properties; the `Property' is a C enumeration (as a type called `uwg_prop_t').

UWG Types

UWG has various enumerated types for certain properties. In WG, these sorts of things were pre-processor `#define's.