W1R4-beta code size is about:
lines KB ------------------------------------ W server 20000 550 W library 6000 130 W toolkit 22000 450 ------------------------------------ 48000 1130Applications have about the same size all together.
About half of the W server code is for the low level graphics routines needed with different screen formats in the W server.
The graphics drivers are in a library that is linked to the W server binary. At the startup the OS/HW specific graphics initialization function, based on the current graphics mode, sets the screen properties (might also first change into some precompiled graphics mode) into SCREEN struct and selects which driver functions will be used i.e. returns a pointer to a suitable SCREEN graphics function pointer table structure.
Currently there are initialization routines for Atari MiNT, 68k-Linux (Atari / Amiga), SunOS, Amiga NetBSD and x86-Linux. Of them the Atari graphics modes are best supported because all the three main developers have ATM an Atari (others modes are tested on university machines or done by other people on the W development mailing list). In any case the two-color nature of the W server kind of nullifies arguments for the high/True Color mode drivers.... The graphics types supported are:
With the COLOR drivers the (two) window colors are selectable. Interleaved bitplanes contain the first 16 pixels on first bitplane, then the same pixels on next bitplane and so on until the next 16 pixels on the first bitplane, then same pixels on the next bitplane etc.
All of the drivers need graphics memory to be linearly accessible. For example on x86 PCs most(?) Super VGA modes / graphics cards use paged memory. The standard 640x480x16 VGA resolution doesn't need paging though (it can be set which bitplanes are written to before changing the bitmap), so supporting it would need 'just' converting the monochrome driver to use little-endian byte order and making up a suitable initialization routine. Any volunteers?
User can attach callback functions to widgets which will be invoked when a certain widget specific action is performed (for example button widget is clicked). There can also be timer and file event callbacks.
After user has created the widget hierarchy/ies and put it/them onto the screen he gives the application control over to the toolkit which will then call the user functions as needed. This way handling the user input is easier and more consistent. Extending and changing the user interface will also be much easier as there are lots of ready made interface components already available. Even complex ones like fileselector, HTML and terminal widgets.
As there isn't (yet) a Wt user interface builder, the widget hierarchies have to be built 'by hand' and tested by compiling the code. After some experimenting with the toolkit this shouldn't be much of a hindrance as long as one keeps the widget manuals (listing the widget options) at hand. :-)
Window partially visible or -DREFRESH compilation option used:
Window on top or fully visible: