Re: Minutes of the GTK+ IRC team meeting - 2010-05-04

[Carlos Garnacho <carlosg gnome org>]

On mié, 2010-05-05 at 09:14 +0100, Thomas Wood wrote:
> On Tue, 2010-05-04 at 23:19 +0100, Emmanuele Bassi wrote:
> > • GtkStyle sealing (garnacho)
> > - garnacho has been working on a GtkStyle replacement
> > - CSS and new API
> > - gtk_paint_* re-implemented on top of the style context
> > - GtkStyle should get sensible data filled from the CSS
> > - engines will have to change, but the API has been kept similar
> > - still needs changed 
> 
> Could Carlos give a bit more information about this?

My proposal is roughly described in
http://live.gnome.org/CarlosGarnacho/ThemingProposal , and the repo is
http://github.com/garnacho/gtk/commits/gtk-style-context

In short, there are these classes:

* GtkStyleSet: A store of style settings, most visibly used by
* GtkStyleProvider: Interface for objects to provide style settings, at
the moment the only implementation is
* GtkCssProvider: A CSS-like resources parser, at the moment there's one
added by default to all widgets to get style from ~/.gtk-2.0.css, more
on the supported format below.
* GtkStyleContext: Per-widget object that will gather information from
several GtkStyleProviders, merging these and also offering further API
for widgets to define regions that can be styled independently in the
CSS parser, amongst other things.
* GtkThemingEngine: Object to implement in engines, the API is similar
to GtkStyle's, but taking a cairo_t*, and removing unused functions and
function arguments that are already in the GtkStyleContext.
* GtkWidgetPath: struct to gather all information about a widget
hierarchy (widget GTypes, names, subregions info, ...). This is used to
query GtkStyleProvider about a widget style, and in GtkThemingEngine in
order to have information about what to theme without having a
GtkWidget*

The idea behind this is that GtkStyleContext and GtkWidgetPath have
enough information for GtkThemingEngine to do its work without having a
direct connection to the widget being themed, so you can replicate a
widget look anywhere you could have a cairo_t*

As for the CSS format, there is currently support for base/text/fg/bg
colors, but the idea is that both widgets and theme engines may extend
the style properties that could be parsed from there. As an example, my
current testing .gtk-2.0.css file contains this:

        * {
            background-color: #333;
            foreground-color: #fff;
            text-color: #000;
            base-color: #fff;
        }
        
        *:hover {
            background-color: #444;
        }
        
        :insensitive {
            background-color: #222;
        }
        
        GtkScrolledWindow GtkButton {
            background-color: #f00;
        }
        
        GtkBox GtkButton,
        GtkTable > GtkButton {
            foreground-color: #0f0;
            background-color: #fff;
        }
        
        tab:active {
            background-color: #22f;
        }
        
        GtkNotebook tab:nth-child(odd):active {
            background-color: #3f3;
        }
        
These parser features are currently supported in that branch, I'm
looking into adding implicit animations (these are only meant for state
changes, and will require a GtkWidget or GdkWindow to invalidate upon)
and further implementing GtkStyle on top of this (currently only
gtk_paint* is redirected to use the newer API).

Also, likely the CSS-like syntax needs extending for symbolic colors,
stock icons mapping and such to be implemented here.

Cheers,
  Carlos