Well, as usual, i want something that'll sound completely crazy
The GUI will be managed by the GUI server (microkernel design), but it will not follow the usual 'low-level drawing commands' ? la X-window nor the 'pre-built widget kit' ? la Java (i will not try to compare to what Wind0z do as i'm pretty ignorant of the bits beyond the main event function).
The concept is that the GUI can host several
renderers which are each specialized to a given task and use a given communication protocol with the clients. For instance, you'll have a
Font Renderer that will be able to draw text you give it, but also a
Html- Renderer that could handle tables, colors, etc. (optionnally using the font renderer to make its work simpler), etc.
You can also envision
PixRenderer that would be able to decode jpg, png, gif and other stuff, or a
FlashRenderer ... All these renderers are sort of plug-ins that will loaded on demand by the GUI server. They might be separated from each other by segmentation if necessary.
Finally, a dedicated language should allow user-defined server-handled widgets: instead of sending every mouse movement back to the client for processing, the client will have the oportunity of
1. send a description of the window topology (so the server can execute the redraw itself)
2. name some specific widgets on a window and receive control socket to these (so that the client can tell the server to change the properties of a given button without having to repaint everything)
3. send a description of how 'common' events should be processed. For instance, a client would not receive any event when the user is navigating a popup menu as long as no item has been selected. The server would have received the code (or bytecode or script ... still uncertain of this) that do the menu popup and navigation (highlight selected entries) even if it's not a default widget ...
Cherry-on-Cake: dialog boxes and other configuration forms should be described in a XML-derivate and processed by a
PromptRenderer that will create the required box, wait for user input, check user input validity and send back an XML document (or
something more packed ...)
Details on what it should look like are already available
.:here:.