Let's create a single theming API specification

Ruslan Kabatsayev b7.10110111 at gmail.com
Sat Jan 15 08:32:48 PST 2011


Hello all,

There are many different GUI toolkits used on free desktops, each
using its way of theming the widgets. Many users look for consistency
between these toolkits.
Some examples of attempts to make this consistency are:

- Cleanlooks for Qt + Clearlooks for GTK+ 2
- QtCurve for Qt3, Qt4 and GTK+ 2
- Oxygen for Qt4 + Oxygen-GTK for GTK+ 2
- MetaTheme (now seems dead)

But these attempts suffer some problems:
1. They multiplicate much code, thus multiplicating effort and bugs
2. They have to take into account some applications, which don't
really use the toolkit these themes are created for, only draw
rectangular regions using these themes (and thus don't support modern
features provided by theme engines). This forces theme engines to
apply ugly hacks to support such applications, making the code harder
to maintain and leading to additional bugs.
3. They aren't universal. Applications can be found which don't use
any of the toolkits these themes affect, thus they won't integrate
into desktop.

Here's (most likely incomplete) list of toolkits and applications
which have different ways of theming, with problems named:

Multiplication of effort:
    GTK+2
    GTK+3
    Qt3
    Qt4
    WINE GUI
Need for ugly hacks because of GTK+ or Qt misuse:
    Firefox et al.
    {Open,Libre}Office.org
    Java
    Opera
No satisfactory way of theming:
    Chromium page renderers
Very differing ways of theming, not allowing to create one single
theme for all (or even most) applications:
    Window decorations

So, i suggest creating a single theming API specification, which would
allow all these toolkits use single library (engine) to draw their
widgets, including most (or all) modern features like these:

- background gradients
- smooth (animated) state transitions
- shadows and alpha-blending
- XShape (instead of alpha-blending when compositing is unavailable)

GTK+ (cairo, in fact) does support drawing on xlib windows
(gdk_window_foreign_new() and cairo_xlib_surface_create() ), i guess
something like this should be supported in Qt.
So, engine programmer would be free in choosing what drawing API to use.

Theory of operation:
On startup, application (in fact, toolkit-dependent engine) calls
single theme engine to get preferred widget metrics.
If possible, these metrics are applied to widgets on creation/resizing.
Also, application registers its callback which would be called on
theme configuration change, so that all widgets are redrawn with new
configuration.
When a widget has to be drawn, application calls single theme engine,
providing it with all necessary information, namely:
- XID
- widget rect
- clip rect
- widget type
- widget state information (enabled, pressed, focused, hovered, default, etc.),
- state of animated transition (number of frame or something like that)
- some other widget-dependent information
Also, since some toolkits aren't able to use X server (e.g. chromium
page renderers), single theme engine should be able to draw to some
pixbuf (e.g. GdkPixbuf) instead of XID.
And, of course, there should be a way for the user to install, select
and configure such unified themes.


I'm pretty new to creating standards and specs, so i don't know what i
should do to start working on it, and make it used. Could someone
advise (and, maybe, join)?

Regards,
Ruslan


More information about the xdg mailing list