Skip to content

Home News Screenshots Wiki Themes Bugtracker Members Logos Search
  You are not logged in Link icon Log in Link icon Join
You are here: Home » News » A new design emerges

Log in
by micah on 2003-01-22 00:00:00

A new design emerges

We're starting to plan what will amount to a large rewrite of several major subsystems in PicoGUI, and plenty of tweaking and shuffling of the rest. There's more info in the mailing list archives, but this basically amounts to:
  • 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 :)