Berlin - Alternative to the X Window System
Down with the X-Wall!
Tobias Hunger
Berlin - Alternative to the X Window SystemDown with the X-Wall!Tobias Hunger |
|
|
More then a decade has now gone by since the development of X Windows. It is not least for this reason that this display system is very robust. Continual new demands from users can be fulfilled with the aid of expansions of the X11-protocol. Despite the far sightedness of its creators, the X Window system is gradually coming up against its limits. 3D applications con only be used efficently with a complicated GLX/DRI mix which does not fit into the architecture very well. Smoothed character sets are still awaited. X also allows only Toolkit related configuration. If you alter your theme in KDE, the appearence of the Gimp does not alter due to the lack of true interoperability.
Fresh start
Berlin offers a central configuration of its appearence. This means that applications present a consistent "Look and Feel" at all times. Gaming fanatics will love the rotating and transparent windows. For programmers the most important feature must surely be the deviceindependent graphics output. The best possible quality is always used, regardless of wether a monitor or a printer is employed for output. As a result, there is no need for the print routines necessary for X, or to adapt a program to different color depths and screen resolutions.
|
Fig. 1: Wether rotated or enlarged: TrueType and Bitmap fonts are improved in quality as the result of edge smoothing.
|
|||||||||||||||||||||||||||||||||||||||||||||||||||
GoalsBerlin's goal is to create an alternative to X11 which can cope better with modern hardware and can be more easily adapted to new input and output devices. The whole system is meant to be modular, so that the actual server is scalable by the selection of suitable modules. Thus the same server should run on both a small PDA and a large 3D graphics workstation. It should also make best use of any available hardware without any changes to its sources. Berlin is trying, by means of abstract interfaces, to develop a system which allows a program to be made usable without alteration in both a walk-in 3D environment as well as in the classic 2D look and potentially even as an "acoustic user interface" for the visualy-impaired. The whole system is being developed under the GNU Library General Public License.
Concepts
Berlin is essentially based on two concepts. The first is that of so-called "structured graphics", where simple objects such as lines, letters, but also transformational functions such as rotations or crops, are integrated into more complex objects. The whole procedure is similar to drafting drawings in vector graphics programs. Figure 2 shows one such (simplified) tree structure and the image created from it. In the example, several glyphs (graphical representations of letters) and a complex vector graphic are combined into an hBox. This element allows all subordinate graphics to be displayed side by side on a common baseline. Model-View-Controller(MVC) is derived from the programming language Smalltalk and is a second concept which is central for the configurability of the user interface. This means that a program ought to be split into three different function groups. The Model contains the status of the program. That could for example be a number of binary states, a variable value in a given interval or a text. The model is processed by one or more Controllers. As soon as one of these controllers alters the state of the Model, the latter notifies all Views involved. The views thus represent the graphical appearence of a program and the controllers its behaviour. In the interest of configurability by the user, both should be as flexible as possible. The actual program logic stays in the model, the logistical backbone. Figure 3 shows how these three components interact. Here, the model consists of three numbers, which represent the red, green and blue parts of a colour. The color field in the middle observes this model. If that changes, the colour changes as well. The controllers here are the sliders. If these are moved, they change the corresponding color values of the model. At the same time they are views too. This is necesarry as the sliders need to move if the model is manipulated by the sliders for the other color system. |
Fig. 2: Example of a structured graphic (above scenegraph, below result).
Fig. 3: The interplay of model, views and controllers. 
|
|||||||||||||||||||||||||||||||||||||||||||||||||||
|
...and their realisation
Berlin uses a so called scenegraph for display. This is a struct ured graphic stored in the server. Here it is possible to see the strict separation of the model in the client and the associated views in the server. In the tree-like structure of the scenegraph, each client is responsible for one part of the tree. The client can insert, process or delete graphics here, thus creating their own illustration. These graphics are demanded by the client from various modules in the server. The entire graphical representation of the clients is found there. Subgraphs (such as a window content) can be affected with the aid of upstream decorator patterns. These patterns are in fact invisible graphics, which affect the appearence of theirt dependents. These can be displacement, rotation, or a change of colour or fonts. The displacement of a window may be caused by its descriptive decorator pattern being inserted in front of the window's subgraph. This causes little or no communication with the client as the server has all the information needed to redraw the whole window. Up to this point no assumptions whatsoever have been made about the hardware used. All details within the scenegraph are abstract. They are also independent of the pixel coordinates and colour encodings of the hardware. For this reason, the normal application developer no longer needs to worry about colour depth, screen resolution and printer support. Berlin adapts the output accurately to the output device in use, regardless of wether this is now a monitor, a video wall or a printer. Various DrawingKits are used to do this. These walk the scenegraph in a so called draw traversal and thereby create an output that can be processed by the underlying hardware. Currently raster and OpenGL display lists are catered for, a Postscript DrawingKit is planned. Table 2 describes individual components of Berlin. These exclude the DesktopKit, which contains functions to control windows, and the WidgetKit, which provides frequently used graphical user interface element. Those Kits have a similar function in Berlin as the various Windowmanagers and GUI-Toolkits in X11.
Interaction
One part of the scenegraph consists of controllers. These are graphic objects which can receive, process and if necessary pass on events. So controllers are special decorator patterns, which alter not the appearence, but the behaviour of their dependents. Any graphics you desire can be converted, into a button for example, by adding a corresponding controller. All controllers are combined into another graph, the control graph. A pick traversal is applied to this, to find the right recipient of an event. Events in Berlin are kept more abstract then for example in X in order to be prepared for future input devices. This also makes events easier to synthesise. Used perhaps to simulate a mouse via the keyboard or to enable a pen-based input on a PDA.
Communication
Sice controllers live in the server, many events can be carried out without any communication whatsoever with the client. The displacement of windows is such an example. The responsible controller of the DesktopKit communicates directly with the transformer of the window. CORBA, with all its functions, seems ideal to take over the communication between server and client-objects. The Berlin interfaces defined in IDL correspond in their function to the X-protocol. But as a rule, communication via CORBA is slower than via sockets. This frequently leads to the assumption that Berlin must be slower then the X Window system. But since the vast majority of communication takes place in the address space of the server, slower communication between client and server is just a bad memory.
Kits
The separation of interface and implementation makes little sense if a programmer can only create elementary objects such as lines, letters or simple controllers. It makes much more sense to create special objects, so-called factory objects. These can make and "wire" complex trees of elementary objects in a single step. In Berlin there are several such factory objects. These are all responsible for a specified type of objects and are combined into Kits. These kits are the mechanism on which the whole modularity and configurability of Berlin is based on. The server itself has just one function - to load kits dynamically at runtime. It does not even need to know which interfaces a kit makes available to do this. It is enough that the application program knows.
Widgets and Taskets
One of the most interesting aspects of drafting user interfaces is the interaction between man and machine. Over the course of time certain metaphors, such as icons, buttons and scrollbars, have been developed. If the architecture itself demands a separation of data and presentation (keyword MVC), it can't be that difficult to design the presentation objects in such a way that their appearance, as well as their function can be configured. What looks to the user like a complex product, perhaps a scrollbar, is displayed as a structure in Berlin. Elsewhere, objects have defined attributes and status variables. Here these are an arrangement of graphic and controller objects, created with the aid of one or more factory objects. The creating kit is the only authority that knows the precise structure. This is the basis for the selection of different display methods. By exchanging the "WidgetKit", a different appearence is archived. More abstract levels can be permitted. When one considers the function of a scrollbar, one notes that it alters a value within given limits. If one takes these tasks, one reaches the term Taskets. When a user whiches to pick one of a list of values, he can do so in various ways ranging from menus, up to radio-buttons. All perform this same task, so implementations can be one and the same tasket. In addition to the WidgetKit, Berlin also provides another more abstract TasketKit enabling the user to select his preffered selection method. This can either demand a radio-button group from the WidgetKit or instead do something completely different. The limit is the sky. A menu for example is less useful than an acoustic response for the visually impaired. The application developer has the option to either impose the appearence of his/her application, by manipulating elementary graphics objects, or work as usual with Widgets. He or she can decided to work with even more abstract objects, such as taskets.
Development status and prospects
It may appear that the Berlin Project has done little in recent months. But there have been a few changes in the internal structure. First of all, many dependencies on other projects have been dissolved. Berlin no longer needs MesaGGI because of the new libArtDrawingKit. A new hardware abstraction layer, the console means that even the dependency on the GGI (Generic Graphics Interface) has now gone. The ORB has now become exchangeable. Apart from this, the whole architecture is more robust. This is the result of improved memory management. Berlin is now truly stable and a bit faster than in previous versions, although there is still a great deal of room for refinement. Nevertheless, Berlin is not suitable for end users yet. Apart from a few demos, there are still no applications. There isn't even a complete set of widgets to develop these. At present, Berlin should be regarded as more of an experimentation field for developing man-machine interaction.
Since the architecture is now in for large sections, work is now slowly b eginning on the implementation of additional widgets. Portage to BSD and other s ystems is in the pipeline, together with the integration of additional libraries such as SDL and GLUT into Berlin. The developers are hoping that this will provide the long awaited hardware support for display. Until now, Berlin has had to manage with just software rendering. At the same time, portage onto an SGI Onyx is in the works. The project team members are hoping to be able to try out Berlin in a real, walk-in 3D environment on this machine. In preparation for this a so-called PrimitiveKit is being worked on. This will make it possible to insert simple three-dimensional objects such as spheres and cudes into the scenegraph. Of course, the development of the so-called canvas widget is not standing still, either. This could be used to embed an X-Server into Berlin. The TextKit is currently in a revision phase, because it still does not provide the bi-directional textflow which will be necessary for multilingual text editing. It is obvious that there is still a great deal to be done before Berlin is seen as the dreamed-of alternative to X11. The team of the Berlin Project would be delighted to recieve any assistance in further development.
Published with kind permission of the Linux Magazine. Comments to this article |
