GUI Architecture Revisited

The GUI architecture is designed to allow several separate applications, running in their own processes obviously, to function together as a cohesive UX system.

Secondly, the applications are expected to use platform services through a single point of access and API.

To achieve this, a TCP/IP communications method is used. Control messages (related to the GUI), service discovery, and service usage is all done through the same channel. To the application programmer, this is not revealed, but instead a collection of APIs are provided. The code for XML messaging over TCP/IP is contained within the code of each service.

So, an application will tell the GsmService client instance to dial a number, the GsmService's client-side code will send an XML-message (via TCP/IP, through "Central") to the actual GsmService process. The GsmService process then uses the underlying platform's native services (via D-Bus in the case of moblin, through CTelephony on Symbian).



Graphically, it is traditionally difficult for separate applications to interact in a seamless way. In Windows Vista, this is achieved by having everything work through HW acceleration. This allows for windows to be rotated and skewed, with their contents still updating.

In a mobile software stack, especially a portable one, the problem of drawing several elements on top of each other in a seamless way, is a more difficult one to solve. In our architecture, it is done by sending offscreen pixmaps via TCP/IP to the HomeScreen. Those offscreens can then be rotated, skewed, overlayed with something else or whatever. Seems to work very nicely!

Below are a couple of shots with separate apps running side-by-side. In the left one, a dialer application sits on top of the HomeScreen application, which draws the card boundaries. On the right, an application is partly covered by the virtual keyboard application.