This is a read-only archive. Find the latest Linux articles, documentation, and answers at the new Linux.com!

Linux.com

Feature: News

New Manju project plans to redraw desktop art

By Bruce Byfield on October 06, 2008 (7:00:00 PM)

Share    Print    Comments   

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.

Manju's solutions

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."

Hidden results

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.

Bruce Byfield is a computer journalist who writes regularly for Linux.com.

Share    Print    Comments   

Comments

on New Manju project plans to redraw desktop art

Note: Comments are owned by the poster. We are not responsible for their content.

New Manju project plans to redraw desktop art

Posted by: Anonymous [ip: 189.35.3.58] on October 07, 2008 01:21 AM
Edje just don't do something like that? And I already saw pretty awesome interfaces done with Edje:
http://labs.morpheuz.eng.br/blog/01/08/2008/qedje-init/

And about SVG theming, I think kdegames already uses something like that. In a convention at Porto Alegre a kde developer showed a game that was themed using a svg, and he could change layout only changing the svg.

I think Plasma also bring some nice ways to do svg themed interfaces.. It could be nice to study all these projects out there before creating something brand new

#

New Manju project plans to redraw desktop art

Posted by: Anonymous [ip: 143.167.200.216] on October 07, 2008 07:07 PM
Edje, KDE games and to some extent Plasma are completely different efforts to this. KDE games use hand-crafted SVGs for each game. Forcing artists to draw every application in order to make a theme would be bad news. The way those games work is nice, but doesn't scale.

Edje is a kind of user interface description, which tells a toolkit like ETK or QT what to draw ("put a button here", "move this image over there").

Plasma allows SVG theming, but is essentially a new toolkit (based on QT's canvas). This means that to take advantage of SVG theming you'd need to completely rewrite your application to use Plasma.

What Manju is trying to do is make a generalisation of the things provided by GTK+, QT, etc. and then standardise an unambiguous naming system and things for them. Then, using this naming scheme, SVG files can be created with the graphics objects given those names (so I can draw a button and call it "button", for example). Finally, these SVGs can be translated automatically into GTK+, QT or whatever, using scripts. In my example the script would look through my SVG for something named "button", then it would turn this into a bitmap graphic (rather than a vector) and give it to GTK+ (probably using a theme engine like Pixbuf) which draws it in place of the buttons. QT would do the same, as would anything else given support for this system.

This abstraction away from the toolkit and translation back means that it can be made more comfortable to make themes, and that those themes can be applied in many toolkits instead of being tied to one.

I'm looking forward to seeing what is possible with this. Hopefully it won't slow things down too much if it catches on.

#

Re: New Manju project plans to redraw desktop art

Posted by: Anonymous [ip: 68.144.80.2] on October 07, 2008 08:19 PM
"Plasma allows SVG theming, but is essentially a new toolkit (based on QT's canvas)"

Plasma is a component system built on top of the toolkit. we have been careful not to create "a new toolkit" and do not actually re-implement the widgetry or what not.

"This means that to take advantage of SVG theming you'd need to completely rewrite your application to use Plasma."

there are two classes that are useful here: Plasma::Svg and Plasma::Theme. neither have any knowledge of or assumptions about widgets. we do provide some ready-made themed widgets for use on the canvas that mate Plasma::Svg with, say, QPushButton.

so you don't need to rewrite your app to use Plasma, you'd just need to have an app that uses QGraphicsView or else handle the painting of Svg->widgets yourself, as you describe being necessary with Manju. the Svgs themselves just sit on the disk under desktoptheme/ so anything could source them .. again, like Manju.

in other words, you are going through and reinventing some of the work we've already done. that's completely cool and totally up to you; the goal with plasma has never been to be a "theme every pixel in every application" project, which is what manju is trying to do.

but it would be nice to (a) actually get plasma's role correct when you talk about it and (b) maybe look at existing art and see where we can cooperate/coordinate.

it would be a shame to see Manju come out with its own definitions of where svg files should be and what they should be named and have plasma and its svg's sitting there as well. there is a pattern that is very evident in projects that start out in the gtk/gnome world wherein there is a tacit dismissal of other work out there without really bothering to understand it and then reinventing the whole vehicle starting with the shape of the wheels.

#

This story has been archived. Comments can no longer be posted.



 
Tableless layout Validate XHTML 1.0 Strict Validate CSS Powered by Xaraya