GUI Frameworks

From HBMobile
Revision as of 00:03, 22 February 2007 by TomCooksey (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigationJump to search

The GUI framework is the software library which allows applications to put pixels onto the LCD. It handles contention between applications, deals with windows and usually provides an abstraction away from pixel-by-pixel drawing through widget libraries.

On a desktop system, this is abstracted into several components: An X-server which allows client applications to connect and draw things in the client's window. Then there are the widget toolkits, where you generally have a choice between Motif, GTK or QT (there are many others, but these are the more common ones). On an embedded system, this split is not always as clear cut.


Back Ends

Frame buffer (FBDev)
Most Linux systems on embedded devices only provide a frame buffer device. This allows an application to memory-map the pixels on the screen and write to them as if it was a regular array. This frame buffer interface is universal across all architectures and all devices, allowing applications utilising the frame buffer to be ported more easily. The disadvantage is that quite often the Application Processor has more advanced graphics hardware for rendering which is not utilized by the frame buffer interface. Enter DirectFB.
DirectFB
DirectFB addresses this problem by providing applications with a more advanced interface. Common graphics operations such as line drawing, blit'ing and basic windowing are provided. When the underlying hardware is able to accelerate these operations, this acceleration is used. When hardware acceleration is not available, the operation is performed in software giving maximum compatibility for applications. While this is an excellent project, the number of hardware devices supported are small and does not include any CPUs you'd find on a phone. This may, of course change in the future.
nano-X
An alternative to using a frame buffer device is to use an x server as you would on a desktop PC. There are many (MANY) applications out there which use X. The problem with x servers are their footprint. Both memory and storage requirements of a normal x server are too large for small embedded systems. To address this, an x-like server has been produced called Nano-X. While not conforming to the X windows API, the API is similar allowing X windows applications to be ported. The last item of news on the nano-x site is dated 2005, so this project may be dead.
Micro-x/kdrive
Unlike nano-x, K-Drive is a complete X server and even supports the RENDER X windows extensions. Although KDrive is a full X Server, it goes to great lengths to not become bloated and is designed with embedded systems in mind. As KDrive supports the RENDER extensions, accelerating drawing operations in hardware is possible, but requires modification for the target Application Processor's graphics core. As with DirectFB, the list of supported hardware accelerated hardware does not include graphics cores found in phones. There is an x server for the HP IPaq, however this simply uses the standard frame buffer and adds support for the VGA-Out device.
OpenKODE
OpenKODE is a new specification for mobile devices and includes OpenGL ES, OpenVG, OpenMAX and similar into a single, integrated API. The emphases here is hardware acceleration. OpenKODE is cross platform and is gathering a lot of industry support. One reason why this might be of interest is rather nicely demonstrated by nVidia in this user interface demo which uses an OpenKODE 1.0 implementation: [1]. There are currently no open source implementations of the OpenKODE specification, however there are OpenGL ES & OpenVG Linux drivers available for PowerVR MBX & SGX cores, found in higher-end [Application Processors].


Widget Toolkits

A widget toolkit provides useful widgets such as buttons, menus, text boxes etc. The application programmer doesn't care what a button looks like, just what happens when it's pressed. On embedded systems, you generally have two choices: GTK+ or QT. However, more advanced, Flash based user interfaces are becoming more popular on mobile phones. Sadly, there are currently no open source equivalents at present.

GTK+

GTK+ has excellent support on embedded systems. Ports of GTK+ have been made for rendering directly to the frame buffer, to a DirectFB device and of course KDrive. For more information about GTK+, visit [2].

QT/Qtopia

QT is a commercial product written by a company called Trolltech. However, Trolltech uses a dual licence scheme where it releases QT under the GPL. This means that if you also use the GPL to license your application, you can use QT for free. QT as it stands is unsuitable for embedded devices due to it's large size and large dependency tree. However, Trolltech now have an integrated product called Qtopia, which includes QT and is designed to work with embedded devices. Out of the box, Qtopia renders directly to the frame buffer. It is possible to accelerate this rendering by re-implementing several of the classes which the library uses to perform all drawing operations. The Qtopia framework also handles windowing when multiple applications are running.


Application Frameworks

The widget toolkits provide facilities for applications to draw buttons on the screen, but what if they want to find a telephone number? On a typical phone, lots of different applications are going to need a contact list. Having a different contact list for each application is going to get silly. Instead, there are two application toolkits available, Qtopia which uses QT widgets and the other is called GPE and is based on GTK+. This is similar to the KDE vs Gnome dilemma, just on embedded devices. The choice between Qtopia and GPE is more critical however. Qtopia applications use the built-in windowing system provided by the Qtopia framework which in turn renders directly to the frame buffer. GPE uses an X-server, which (usually) also renders directly to the frame buffer. The result is that it's a one or the other thing. GPE applications can't run simultaneously with Qtopia applications. Once way around this would be to port Qtopia (back) to X windows and let the X server handle windowing.

GPE Palmtop Environment
from GPE's homepage: "The GPE Palmtop Environment aims to provide a Free Software GUI environment for palmtop/handheld computers running the GNU/Linux™ operating system. GPE uses the X Window System, and the GTK+-2.6 widget toolkit.

GPE is not a single piece of software, but an entire environment of components which make it possible to use your GNU/Linux handheld for standard tasks such as Personal Information Management (PIM). GPE makes it easy for developers to create powerful programs, by giving them the infrastructure they need.

Besides providing core software such as shared libraries, and perhaps more importantly, the GPE environment fixes standards for program interaction, such as SQL, XML, and other data schemas."

A recent development has been the launch of GPE Phone edition. This aims to implement a complete LIPS compliant software stack.


Qtopia