A toolkit independent widget drawing API

See: http://mail.gnome.org/archives/gnome-themes-list/2008-July/msg00017.html

Codename: Monet

Repository: http://git.gnome.org/cgit/monet/

Motivation

• Provide a way to help multiple toolkits achieve a similar look and feel
• Reduce the number of hacks needed to get a nice looking desktop

Goals

There are basically two consumers of this project: toolkit developers and users. Each has their own set of requirements, but can be summarised as follows:

1. Provide toolkit developers with an API to draw and style their widgets
2. Provide end users a way to customise the appearance of the toolkit

The individual detailed requirements are covered in the two corresponding sections below.

1. API Requirements

This section covers the requirements of toolkit developers. It is important that although cross toolkit compatibility is highly desired, it should not be to the detriment of the design.

• Provide a drawing API to draw simple and complex widgets, and also abstract drawing functions such as shadows. Complex (composite) widgets can be divided up into separate components.
• Provide a data API to allow the toolkit retrieve information such as text colour, and padding properties that may be needed before rendering a widget (e.g. a toolkit will need to know the padding values of a widget to determine its minimum size).
• Provide a list of available styles and allow the toolkit to add and remove from the list, and also select which one style to use.
• Define the API as a common interface that could be implemented and used to achieve native appearances on other platforms. This would be as a replacement library as it may possibly require much greater integration with the toolkit.
• Consider possibility of animations, both between states and persistent (looped)

/Api

2. End User Requirements

End users require a way to create, edit and apply different visual styles to their user interface.

Creating and editing of visual styles should be done with the aid of a GUI application. It would be of great benefit if this was developed alongside the development of this project.

The styles themselves need to be stored in a well defined format. Possibilities include:

• CSS: Advantages: well known syntax, moderately flexible. Disadvantages, limited to a small set of drawing operations, most complex drawing will require falling back to 9 slice image manipulation or would have to use vendor extensions.

• SVG: Advantages: allows complex drawing operations. Disadvantages: may need some extensions to support all the definitions needed.
• Script: Advantages: very expressive, flexible. Disadvantages: would need a custom editor, custom documentation, training for theme developers.