The future

After the 2.6 release, we will concentrate on Cairo support in GDK. Cairo is a relatively new graphics library that closely matches the future rendering needs of GTK+. It is designed to be an easy to use 2D graphics library offering a rich set of capabilities and multiple output backends.

The Cairo API is similar to PostScript. The example shows how to construct a path from points. Cairo also has functions to create common types of paths like rectangles, arcs or circles. Cairo goes beyond PostScript by including complete alpha-compositing (not shown in this simple example, but there are many more interesting ones on http://cairographics.org).

In rough terms, the rendering capabilities of Cairo are comparable to those of Java 2D, SVG or PDF 1.4. In detail, Cairo doesn't offer all that SVG or PDF offer, but that is mostly due to their declarative nature. They have to provide everything, while with Cairo, the application has ample room to build richer systems. It is for instance possible to let Cairo render into a local buffer, tweak the pixels directly, then use the tweaked buffer as source for further rendering operations.

Cairo already has backends for X, OpenGL, PostScript, and local image buffers. The OpenGL backend has seen a lot of work recently and shows that Cairo can be efficiently accelerated on modern graphics hardware. The PostScript backend is still very basic, it just writes a huge bitmap to the PostScript file, which is of course not how you want to render a document. A real PostScript backend needs to be a very sophisticated in figuring out what parts need to be send as bitmaps, and what can be rendered using PostScript operators. This is necessary, since the Cairo (~PDF) rendering model is much richer than the PostScript model. While this is a programming challenge, it has been tackled in such software as OpenOffice and ghostscript, so it is definitively doable. A simple way out would be to write a pdf file and let ghostscript deal with the conversion to PostScript.

The traditional GDK rendering API, which wraps the Xlib drawing functions will not go away; Cairo will be an additional rendering API. Most likely the Cairo support in GDK will not wrap the complete Cairo API, it may consist of a single function which connects GdkDrawable and a Cairo surface and redirects drawing from the surface to the drawable. The reason for wrapping the entire Xlib drawing api was that the Xlib functions require explicit Display and Window parameters all the time, which makes them cumbersome to use. Another reason was that GDK allows other backend implementations beside the Xlib one, e.g. the Windows backend. Cairo on the other hand, already offers an API very similar to what the GDK wrappers would look like anyway, with a single cairo_t context parameter. And Cairo already supports multiple backends, so wrapping it again in GDK would create multiple levels of wrapping.

A big advantage of not wrapping the Cairo api further is that we don't have to maintain the wrapper layer as Cairo develops further. We don't have to maintain separate documentation. A small disadvantage of not wrapping Cairo is that the naming conventions don't match exactly (cairo_font_t instead of CairoFont, cairo_font_reference() instead of cairo_font_ref()) - application programmers will learn to live with it. The fact that Cairo doesn't use GObject causes a bit more work for language bindings. But we are convinced that the benefits outweigh the disadvantages.

While Cairo allows to do rendering with an alpha channel, the COMPOSITE X extension allows windows to have an alpha channel. While the usefulness of this is often overrated, it allows for neat 'glitz' effects like fading in and out of menus, or proper drop-shadows. GDK will support this by offering API to find visuals and colormaps with an alpha channel.

Theming is a difficult issue because there is an inherent tnesion. On the one hand, we want to have themes that can control precisely how GTK+ renders, and we want to be able to extend GTK+ with new widget types. The considerations argue for a theming system that is tightly integrated with the way GTK+ works. On the other hand, we want to write themes that chain to a platform native look: the WIMP theme has done this very effectively for Windows. And we want to be able to use the theme system to render third-party widgets, as is done by e.g. OpenOffice or Mozilla. These considerations argue for a theming system that is much more closely tied to the idea of a "standard set" of widgets. Finally, it has to be possible for libraries and applications to create new widgets and have them work with themes without the theme having explicit knowledge about the new widgets.

The current theme system in GTK+ was developed with knowledge of the above issues, and the attempt was to create a maximally flexible system. The way it works is that a theme provides replacements for the standard paint functions corresponding to different basic widget components: flat and beveled boxes, checkbutton indicators, arrows,notebook tabs, etc. These functions are called to draw the actual widgets, and they receive the drawable and area to draw in, but also some extra information: an unspecified detail string, and a reference to the widget itself. The idea is that by providing basic implementations of the functions, a theme can minimally render any widget, but it can also use the detail string or even the widget pointer to special case and improve the rendering for particular widgets. The theme engine and generic and theme specific options are bound to particular widgets using the gtkrc file which is written in a custom language whose syntax vaguely resembles C.

The theme system currently used in GTK+ has been successful in the sense that people have generally been able to get widgets to appear as they want, but the system has a number of big shortcomings.

• The style functions take a detail parameter, which is a freeform string. The set of used detail strings is unspecified, and style functions have to do a considerable amount of special-casing based on the detail strings in order to render all widgets reasonably.

• There is no concept of layout in the theme system. All layout decisions are done in the widgets. This means that it is not possible to write a theme which rearranges the controls in the color selection dialog, unless the color selection dialog defines a style property for this purpose.

• The style functions are very hard to use for rendering non-GTK+ widgets, yet this is desirable to match the appearance of GTK+ in applications written in other toolkits, e.g. OpenOffice or Mozilla.

A new theme system should address these issues.

• It should be fully specified to avoid the detail string mess.

• It should provide access to layout of composite widgets.

• It should emphasize declarative ways to write themes, and the declarative parts of a theme should use a standard syntax like XML or even CSS. The unavoidable imperative parts should not depend on GTK+ internals, in order to make them useable for non-GTK+ widgets. Using Cairo as the rendering API for themes would go a long way towards achieving this.

The missing print dialog is one of the more glaring holes in the widget set. libgnomeprint and libgnomeprintui offer a print dialog, but the natural place for it to live is GTK+. Having Cairo support in GDK will make this easier, since Cairo already has PS and PDF backends. The print dialog will be implemented similarly to how the new file chooser works, with backends for the various printing systems: CUPS and maybe lpr for legacy Unix systems, GDI on Windows.

Introspection (also known as "Reflection", or "typelibs") means that GTK+ offers information about its interfaces in a form which can be programmatically used. GObject currently offers information about the type hierarchy and implemented interfaces, and about signals and properties of objects. This information is successfully used for creating automatic language bindings, it is used by gtk-doc to automatically generate a good amount of the GTK+ reference documentation. It could also be used to help with code generation and code completion in IDEs, although I don't know if there are any such projects currently using the GObject introspection.

To make the introspection mechanism of GObject even more useful, the virtual function slots in class structures and the ordinary library functions should be made available. This should allow fully automated language bindings, and would allow IDEs to assist in deriving new classes from existing ones, by knowing which virtual functions can be overridden, and what their signatures are.

Many other interesting, "blue-sky" ideas for future GTK+ development can be found on http://www.gtk.org/plan/2.6