Gtk3 and theming - a proposal (with code)


After the CSS engine [1] has gained some traction -- at least in terms
of code -- I'd like to lay out a possible plan for theming in gtk3.

First up, some (well known) issues to consider:
  (1) "Suboptimal Theming in GTK" [2]
  (2) "Themes are Evil!" [3, 4]
  (3) Lookalike widget/toolkit implementers are unhappy with gtk's capabilities.
  (4) Win32/OSX (and also some gtk/x11) developers feel the theming
API doesn't really cater to them [5].

Proposal / Discussion

Owen Taylor proposes the creation of a standalone theming library [6],
this is what I have done. After proofing the concept of CSS styling
for gtk with two releases of the CSS engine I have now spun off
libccss (the `Cairo CSS drawing library') [7] into a freedesktop
project of its own. The code is a flux right now, as API and internal
representation are enhanced after clutter/tiny developers have
expressed interest in using it for their own styling efforts.

So, what do you think about getting rid of gtkrc entirely and using
CSS instead for gtk3? Apart from non-technical reasons like designer
buy-in and QT already using it, it will also
  + Allow for fine-grained matching ( "h-button-box" example:
  + Make order of theming statements irrelevant (I have learned that
this is required now to theme network-manager's tray popup).
  + Facilitate easy theme prototyping using html and a web browser.
  + Lend itself to the creation of graphical theme design programs.

Ad (1): This should be alleviated by the proposed approach, because
there will be a well-defined interface querying primitive- and
widget-styles and drawing them.

Ad (2): There's not so much we can do as long as arbitrary engines are
involved, but cutting down the desire for engines by providing
appropriate capabilities in gtk proper should limit the need for wacko
engines. (libccss has already seen some valgrind scrutiny).

Ad (3): They can just use libccss, no more need for offscreen
treeviews to get the header-button drawn correctly and similar hacks.

Ad (4):
* As regards X11, I keep hearing that the theming API is going to be
fixed. However, IMO caution is due. Working on the CSS engine I've
seen that the engine API is extremely versatile, big kudos to the gtk
developers for that. Most of the problems really come from the engines
and their (mis)use of the API, rather than the API itself. I may quote
Havoc Pennington from [8]:

    Deprecation should be about fixing things that were previously
    impossible, or  things that were outrageously inconvenient, or
    things that are unfixably broken. It  should be  enabling 100%
    better not 5% better.

* As regards non-X11, I think it would be favourable to also support
CSS on those platforms. The CSS3 UI spec has info on native appearance
of widgets, supporting something along those lines with gtk-built-in
CSS capability would seem fit.


* Use CSS inside Gtk3 instead of gtkrc.
* Use a 3rd party library (libccss) for drawing.
* Keep the drawing parts of the engine interface, but engines move to CSS too.
* Engines don't have to parse themselves any more, they can use custom
CSS properties which are supported and parsed by libccss.
* Regardless of X11 or non-X11, when "native" appearance is specified
through CSS3 appearance settings by the theme's CSS the drawing calls
are dispatched to the engine (if available).
* If the engine doesn't support a requested primitive gtk falls back
to using libccss.

[5] Talk to Benjamin Berg and Alberto Ruiz

This should provide some insight on what I'm up to. Let me know what
you think, and maybe the Dublin hackfest can be used to bring things
on track.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]