A new design emerges

• Microkernelization

  This would involve breaking up pgserver into a constellation of "servers" for the widget tree, layout engine, rendering engine, themes, input, and widgets. These would communicate through a custom very lightweight RPC-like library. If you wanted pgserver to be a single binary, the RPC layer would optimize out into plain function calls. If you wanted shared libraries, the layer would become calls to dlopen()'ed libs. If you wanted them all on separate machines, you could use TCP. This would make the code easier to maintain, easier to experiment with, and more flexible. The theme server could be replaced without disturbing the others, in order to design alternative theme systems. You could connect multiple layout engines to one widget tree and view the same apps at multiple resolutions simultaneously.

• More intelligent memory management

  All handles in pgserver would be reference counted, making it much harder to accidentally leak the server's memory when writing clients. Specialized allocators for several frequently-reused types would be provided, similar to the "zombie gropnodes" used now.

• New rendering engine

  The "S2 engine" that I have been planning on implementing would take shape, in the form of the new default rendering engine. Going along with the microkernel idea, it will be possible to replace the S2 engine with libart or another renderer in order to do postscript and SVG rendering.

• New layout engine

  This might be similar to the current layout engine but with some of the limitations removed, or it might be something completely different like a constraint solver. It will have optional support for floating point coordinates, and affine transformations.

• New configuration and build system

  The SCons-based system I have been planning will be used from the ground up. The entire PicoGUI system will be configured as a whole, with usable dependency analysis and interfaces to both external libraries and external distro buildsystems.

• More real-time

  The current input system falls victim to the same FIFO queueing delay that most GUIs are vulnerable to. PicoGUI should provide a way to quantify and limit the latency between input and response.

• More consistent widget model

  PicoGUI widgets should be completely based on property get/set and event passing, rather than only mostly. Widgets should be able to monitor data for change and react immediately, through a node-monitor-like system for handle objects.

• Better revision control system

  The new source tree will be developed in something better than CVS, probably Subversion or Arch.

• New name?

  To reflect all these changes, we might have a new name. Or not. This is still undecided

Well, that was quite a mouthful. Obviously it will take some time to rearrange, rewrite, and write code for the new system, but I'm confident it will be worth the effort. In PicoGUI's current state it will be fine for PDAs, but it lacks some of the features necessary to achieve the amount of scalability I've been envisioning PicoGUI having. While the new tree is being developed in a separate repository, the current CVS tree will still be developed.

Thanks to Lalo and Nathaniel for all the ideas above :)