Re: Gtk3 and theming - a proposal (with code)

["Alberto Ruiz" <aruiz gnome org>]

2008/10/8 Robert Staudinger <robert staudinger gmail com>:
> Hello,
>
> 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:
> http://www.gnome.org/~robsta/gtk-css-engine/screenshots/child-index-selector.png
> ).
>  + 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.

I don't quite agree with that, it doesn't allow things that would
actually have a huge impact if we were to move to CSS.

I think that the new API should not allow people to acess to
GtkWidget, this prevents implementation changes since engines end up
depending on Widget implementation details (such as the way containers
are used and where in those containers are the elements placed, I'm
thinking in "TreeView > Label" precedency use case here). I think
GtkStyle should go away and be replaced by something that would
provide this information.

Another huge annoyance is the inability to provide information about
siblings, at the moment, the only way to inform about those things is
the detail string, and once is set, you can't change it. We couldn't
use most of the css selector patterns such as "Label + Entry" or
"Notebook.tab:first-tab". Again, the GtkStyle replacement should
provide that context information.


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

>
> Conclusion
> ----------
>
> * 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.
>
> [1] http://mail.gnome.org/archives/gnome-themes-list/2008-October/msg00000.html
> [2] http://abock.org/2007/07/02/suboptimal-theming-in-gtk/
> [3] http://blogs.gnome.org/mortenw/2007/05/27/themes-are-evil/
> [4] http://blogs.gnome.org/mortenw/2008/02/02/themes-are-evil-part-ii/
> [5] Talk to Benjamin Berg and Alberto Ruiz
> [6] http://lists-archives.org/gtk-devel/07927-guadec-theming-api-meeting-minutes.html
> [7] http://anongit.freedesktop.org/git/ccss.git/
> [8] http://mail.gnome.org/archives/gtk-devel-list/2008-September/msg00216.html
> [9] http://www.w3.org/TR/css3-ui/
>
> 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.
>
> Best,
> Rob
> _______________________________________________
> gtk-devel-list mailing list
> gtk-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/gtk-devel-list
>



-- 
Un saludo,
Alberto Ruiz