Shared Framework

From Tango Desktop Project
Jump to: navigation, search

In order for the Tango project to be succesful across desktops, it follows logically that we need a cross-desktop theming specification.

Federico rants on themes

Concrete proposal

1. What approach does Tango favor?

CSS is the W3C standard for doing layout on web sites, and allows extensive theming of them.

XUL is the Mozilla framework for writing themes and applications. It is based on XML, CSS, and JavaScript, and allows you to completely change the look of Mozilla. XUL is, in other words, an example how CSS can be used in much broader ways than simply doing layout and theming on web sites.

If we followed Mozilla's lead and build proper CSS support into our toolkits' engines, we could use CSS on the desktop to allow the layout and style of an application to be completely altered.

2. What problems would this approach solve?

This would solve many of the issues with trying to create a cross-desktop Human Interface Guide, as it proposes to allow definition of application layout in the theme, rather than in the application itself. Spacing, padding, button order, and other parts of layout would reside in the theme, rather than in the application. This allows the Human Interface Guide to become more of a guide for devoloping usable applications by suggesting what language to use, what widgets to use for different types of user interaction, and how to design an application, rather than being a document that defines button order, layout, and spacing.

What this means for application developers, is that there would be no specific HIG that they needed to follow. By moving the definition of application layout and style to the theme, we separate them from content. This means that application development and design can be separated into multiple teams more easily.

Another advantage to using CSS is the unit types it uses. By using em and percent values as units, we can create themes and application layouts that scale much better to higher resolution screens. Using pixels to define spacing and layout of applications as we currently do, means that the applications don't scale to higher resolution displays.

Using CSS would also help improve the internationalization of applications, by not requiring markup for making text bold, underlined, larger, smaller, or use a different color, to be in the string itself.

3. Are there other options?

While there have been various proposals to solve this in other ways, most of them involve non-standard theming formats.

Enlightenment has something similar to what this document is talking about, however, it is non-standard, and a new binary compression format containing various bits of a compiled theming language. The implementation is very powerful for changing the behavior of an application written with the Enlightenment libraries, but it makes it somewhat difficult for theme authors and artists to get things done easily.

Another approach to this problem is the Metatheme project. This project basically creates a new theme engine API, similar to the gtk engine API, and then tells various toolkits to all use it's engine backend to load the custom engines for it. This solves the problem of making various toolkits look the same, but because it solves this problem by creating an API, artists would still need to have someone write an engine for them when they want to implement their themes.

Further, the Metatheme approach only handles the color/style side of things. By contrast, our CSS proposal is meant to encompass application layout as well.

4. Tell me more about the advantages of CSS

There are two main advantages to using CSS for this effort. First, CSS has the advantage of being a widely accepted standard, backed by heavy use in the web space.

Second, most artists already are well versed in its syntax, as they use it to define style for their web pages. Many applications for OS X also allow defining style and layout through CSS. This allows OS X theme authors to easily port their themes to Linux as well.


5. What should our next steps be?

Migrating to this for just simple theming of color and style, should be fairly easy to do. We already have the ability to theme the different toolkits using their native theming formats. And, we also already have various CSS parsing libraries to allow us to handle CSS in the backend. The parser used by the SVG handling library in GNOME, libcroco, should allow us to easily add CSS parsing support to a theme engine for GTK . Other potentially usable CSS parsers are the ones used by Mozilla Firefox and KHTML in KDE. The use of XUL in Mozilla projects is a concrete example of being able to do what we want with CSS. A simple example of using CSS for widget colors, based on GTK naming conventions, would be:

widget.NORMAL { background-color: #efefef; }


One way to simplify this further, is to write an engine for Metatheme which uses CSS to define the style and colors for the theme. This would mean that we get GTK , QT/KDE, and Java Swing support, immediately. Metatheme would need to stabalize quite a bit before we could take this route though. The API looks simple enough to use, and similar to the GTK engine API, and the Industrial and Plastik themes are already ported, meaning that sufficient code has been used to do this.

It will take quite a bit longer to move the various toolkits to layout engines, where the layout can be defined in CSS, and the backend does all the drawing according to the CSS rules. Creating the layout backend support means migrating toolkits to a new layout mechanism, and porting applications to define their container structure in a way that the themes can easily lay them out differently. Projects using the Mozilla framework are going to need the least amount of change, as they already have support for defining layout and color in CSS. GTK and similar toolkits that use a box model for container structure should be easy enough as well, given that it would be easy to create a DOM structure out of the container tree. Maintaining backward compatibility for the GTK , QT, and other other toolkits is not going to be easy though, and very likely, not possible. We should encourage changing the layout method in a major revision that is allowed to break backward compatibility, only.