Disko Framework Architecture

General

The Disko framework aims to simplify the development of complex and flexible applications for embedded Linux systems. There is a particular focus on the development of user interfaces, which are easy to maintain.

Dependencies

The Disko framework has been developed in C++ and all the functions required for the software development will be made centrally available. As well as the interface for creating and programming user interfaces, this also includes several other necessary functions, such as data administration, protocolling, configuration and communication.

Some of the available interfaces offer various implementations of basic libraries, which can be selected during compilation or runtime, e.g. xine or streamed as a media player interface. This enables a flexible choice of software and, thus, improves the integration of new software applications into the existing environment. As a result, interfaces are designed so that even proprietary developments can be linked to the existing interfaces ie. a proprietary media player library. During compilation, there is the possibility to select which functions should be (de)activated. Ever since development work started for Disko, we have tried to limit the dependency of other basic libraries as far as possible.

Hardware Independent

Great emphasis has been placed on the support for different graphical interfaces during development, as Disko should support a variety of hardware platforms. Currently, several graphical environments are supported, such as x11, DirectFB or the normal Linux Framebuffer. The low level API provides sufficient functionality to port the Disko application easily into various environments.

Disko Services

As well as low level API, Disko also supports high level API functionality. This includes, for example, window and input management, theme management, time-linked data import, as well as an interface for multi-lingual management. These functions can be used independently of each other, depending on the specific requirements for the application.

Application Architecture

A typical Disko application consists of several plugins, which determine the level of functionality of the actual application. Plugins can be loaded during runtime or statically linked to the application at compilation, without losing the ability to (de)activate these during runtime. This approach allows the reuse of partial components, to improve code quality and to create a stable overall system. Disko offers the possibilty of sending events in the system or to subscribe to messages, so as to link independent plugins to the overall system. These messages can not only be sent cross-application, but also via TCP/IP across application and system boundaries.

The idea of an independent plugin requires a central component, which guarantees low cost and good product performance right from the start. This component is the plugin switcher, which is a fixed part of the Disko basic installation package. The plugin switcher can also be updated and/or self-implemented if needs be, so as to serve specific needs and requirements of the application without difficulty.

The Disko GUI Component

The Disko GUI component is made up of several different layers. The top layer manages the various application windows and dialogs which are used in the application. These dialogs are optimally described with the help of XML files, which are loaded, processed and interpreted by the window manager during the run-time. This process allows the use of the MVC framework, which strictly isolates the application logic from the description of the user interface. To limit the comparatively large effort involved in processing XML files, all XML descriptions and visual files are converted into a special internal format when the program is first started, to remove the need for repeated reading and processing of dialog files. Each time the program is started, it checks whether newer XML files are available, which can then be converted into the internal format where necessary. This allows the greatest possible flexibility in creating, maintaining and servicing the software, while avoiding the usual disadvantages of using XML.

The middle layer of the GUI component manages two different layers, blit routines and an underlying simple window management. The implemented character functions already support a variety of pixel formats, so as to offer a broad foundation of hardware support. For performance reasons, Disko uses its own internal pixel format, which can differ from the output pixel format. When the internal format is set to a transparent format, transparency is available in every combination for the whole user interface.

Disko always provides two internal layers for application development - the video layer and the graphics layer. This facilitates the development of more complex software applications and increases their portability. The number of layers provided by the hardware does not need to be considered, as due to special framebuffer implementation, the environment provided by the hardware is always used (including hardware acceleration). If no multi-layer hardware support is available, all operations are carried out on the software side, and the application remains fully functional. Disko so far supports various hardware platforms, such as the standard framebuffer, x11, DirectFB or OMAPDSS2 framebuffer.

.