Author: Bruce Byfield
Most free software projects produce applications for users. A minority, however, produce specifications or libraries for developers and other contributors. An example of this second type is the recently announced Manju project, whose goal is to make themes easier to create. The project’s goal is to write the specifications and scripts for using scalable vector graphics (SVG) files to store widget and other theme-related information that can be used on a variety of toolkits.
Manju was started by Andreas Nilsson, an artist who has contributed to the Open Clipart project, Inkscape, GNOME, and Scribus, and Tim Janik, a long-time developer of the GTK+ toolkit.
A major motivation for the project seems to be the limitations of the GTK+ toolkit in particular. Janik, who in 2005 started the Rapicorn project as a sandbox for toolkit experiments, expresses particular impatience with the limitations.
“GTK has reached the point where it is so mature that not many experiments can be done with the code base any more,” Janik says. “It’s not a project that’s useful for prototyping.” However, Janik does hope that work done in both Rapicorn and Manju will eventually become part of GTK+ as well as other toolkits.
Problems in theming
Manju was born from a conversation between Nilsson and Janik at this year’s GUADEC conference in Istanbul. It is designed to address a number of problems with the GTK+ theming engines.
Janik explains that GTK+ theming is a “historical growth” begun a decade ago, and, as a result, “not everything that you’d like to change in a theme can be adjusted in GTK.” For example, according to Janik, rounded corners and transparency is difficult in child windows.
Moreover, the functions that draw frames for widgets can use only one size of images, and widgets can therefore be hard to resize when the screen resolution is changed, or when the same icon is used in a menu as well as on a desktop.
Initiatives like the Tango Desktop Project have got around this resizing problem by providing icons and widgets in several different sizes. But the problem with this solution is that it requires the maintenance of a different file for each size, and keeping both images and color palettes consistent — a process that Janik describes as “tedious” for the artists.
This tedium is heightened by the fact that the GTK+ styling system requires some learning that artists would prefer to avoid. Other toolkits, including Qt, Mozilla’s Xul, and the Hippo Canvas used by the One Laptop Per Child Project have responded by using Cascading Style Sheets for theming, which has the advantage that many artists are familiar with it. But, as Janik points out, while many aspects of CSS, such as colors, sizes, and fonts, are applicable to user interface design, many are not. And, since CSS was originally intended for use with HTML, a very limited format, chances are that its lack of flexibility will sooner or later become a problem. Manju’s goal is to provide a simple solution to such problems.
Borrowing the popular concept of the one-canvas workflow that has become popular in recent years among designers, the Manju project plans to use a single SVG file for each theme. This file would include such information as widget design at various sizes, as well as the color palette, all clearly labeled. Scripts would extract objects as needed, and the objects would then be converted by Inkscape running in the background into pixmaps for display. Janik explains that, while SVG is the most convenient format for storing files that will be resized, SVG rendering is vastly more complex than pixmaps and likely to be slower; besides, toolkits are already set up to handle pixmaps.
In addition, Manju also needs to write the code to pass the results of this processing to programs, and to create the metadata to be added to SVG files about how to render images. In particular, Janik hopes to provide a graphical way for artists to choose the parts of an object that are altered when an object is resized.
For example, in drawing a rectangle, instead of specifying that pixels will be added to pixels four, five, and six on a side, using Manju artists could simple select the area that will be stretched — a change that requires them to be less concerned with specifics and to focus on design.
Another goal of the project is to create a binary format that can use something like GTK+’s icon cache, so that commonly used images can be loaded once into RAM, thereby increasing the speed of rendering and reducing memory use.
The result of the Manju specifications, if Janik has his way, will be a system that is much easier to learn for artists, and more efficient for artists and developers alike.
“It’s going to be much easier to define themes using Manju than using existing toolkits, especially GTK,” Janik says. “Because, as an artist, the only thing you have to do is create one of those SVG files for the theme.”
But all these advantages are only possibilities. For now, Janik says, “Manju needs artistic input. It also needs code for the extraction, and the example code to demonstrate how SVG theme files can be used for toolkits.” Once that work is done, “it also needs integration into existing toolkits. And this is something that can’t really happen within the scope of the Manju project, because it is just providing the necessary groundwork. It depends on contributors to the individual toolkits” — especially GTK+ and Qt.
In other words, Manju is intended as a project for experiment and innovation, and its success depends on whether toolkits are willing to adopt it.
If it does become widely used, then end users should benefit from more themes, as well as more complex ones — though most of them will never know what has happened. It is mainly the artists who will benefit, and the developers who will decide Manju’s future.
- Graphics & Multimedia