Re: gtk-style-context notes

[Carlos Garnacho <carlosg gnome org>]

Hi Thomas,

On Thu, 2010-10-14 at 14:20 +0100, Thomas Wood wrote:
> On Thu, 2010-10-14 at 12:19 +0200, Carlos Garnacho wrote:
> > Hi Benjamin :),
> > 
> > On Wed, 2010-10-13 at 18:40 +0200, Benjamin Berg wrote:
> > > Hello,
> > > 
> > > So, some notes about the gtk-style-context branch.
> > 
> > Thanks for reviewing the branch. FYI, I'm currently in the process of
> > documenting the changes, I was planning to send a mail here once there's
> > some docs that cover the different aspects.
> 
> One other aspect I'd like to mention is the theme engine API. Currently
> it's possible for theme engines to hook into the gtkrc parsing and add a
> custom parser. I noticed that there is a function that allows theme
> engines to register new properties, but how would a theme engine like
> the pixbuf engine be able to parse custom syntax?

The custom syntax would be enclosed in the CSS property value, it is
possible to install parsers for these, so doing:

        gtk_theming_engine_register_property (engine, "pixbuf",
                                              GDK_TYPE_PIXBUF, NULL,
                                              _engine_pixbuf_parse);
        
would allow doing in the CSS:

        * {
          -EngineObjectName-pixbuf: foobar.png 1 2 3;
        }
        
_engine_pixbuf_parse() would be responsible of parsing "foobar.png 1 2 3
" and produce a GdkPixbuf value out of it.

FYI, there is already support for background-image (Although it just
supports gradient patterns ATM) and border-image (also supporting 9slice
for rendering at different sizes), so this is supported by the CSS
parser:

        GtkButton {
          background-image: -gtk-gradient (linear,
                                           top left,
                                           bottom left,
                                           from (shade (@bg_color,
        1.1)),
                                           to (shade (@bg_color, 0.7)));
          border-image: url (button-border.png) 4 4 4 4 repeat stretch;
        }
        
> 
> Also, some engines (such as the windows engine, see msw_style.c) want to
> set style property values based on platform API calls. Currently this
> has to be done by constructing a string and calling gtk_rc_parse_string.
> Will there be an better way to do this in the style-context branch?

For the windows theme usecase, I think it makes sense to have this piece
of code in GTK+ itself. GtkSettings has already a similar role in that
it has  information about symbolic colors and font size, this is hooked
up into the theming machinery by having GtkSettings implement
GtkStyleProvider. So I think it makes sense to put this into
GtkSettings.

If this is badly needed in other places, there is a per-screen list of
GtkStyleProviders, shared amongst all GtkStyleContexts in that screen,
so a theming engine could theoretically add a custom style provider for
its screen. Although this is a hackish solution I wouldn't advise. 

> 
> 
> > > 
> > > The gtk-style-context branch mirrors the current drawing functions very
> > > closely. I know that this requires quite some work, but there are some
> > > things that can easily be changed now:
> 
> We've talked in the past about moving away from abstract drawing
> functions to more widget focused functions. This would help custom
> widgets that want to mimic existing widgets and it would also make it
> easier for other toolkits to mimic GTK+. What are your thoughts on this?

I think this pertains to a higher layer, if we want to fully mimic both
simple and complex widgets, I think we need full MVC, and the rendering
still has to be splitted piece by piece somewhere.

There is also a problem in user interaction, the simplest of complex
cases I can think of is the spinbutton, it doesn't make sense to render
a spinbutton as GTK+ would if the clickable areas are going to differ.

For simple cases (that construct more complex ones), I'd advise pushing
for a standard set of class names, so for example:

        .entry { ... }
        .button { ... }
        
would respectively style all widgets using the "entry" and "button"
classes, while:

        GtkSpinButton.entry { ... }
        GtkSpinButton.button { ... }
        
would style a GtkSpinButton entry and buttons respectively.
        
> 
> 
> > >  * Make focus just a simple flag (that can also be checked from the CSS)
> > 
> > There is GTK_STATE_FLAG_FOCUSED in GtkStateFlags, it can already be used
> > as any other state flag (including transition animations), but you are
> > right in that this isn't hooked to the CSS parser yet, should be matter
> > of adding a new scanner symbol in gtkcssprovider.c, create_scanner().
> 
> If there is a flag for focused widgets, would this mean you could remove
> the "render_focus" function? Or would this function just be omitted from
> widgets that support the focus flag?

Good point, I guess it can go away.

> 
> 
> > > 
> > > It may be possible to get rid of the text/base vs. fg/bg color pairs,
> > > and instead just use one set of colors with different values depending
> > > on the widgets (ie. any "input" widget like GtkEntry, GtkTextView,
> > > GtkTreeView would get a white background, while the rest is gray).
> > 
> > I've been thinking back and forth about that. As far as I can see,
> > mostly depends on what the plans are for GtkStyle if this branch gets
> > merged in, If we only have GtkStyleContext, we can have per-class and
> > per-region styling, so for example a spinbutton can use different colors
> > when rendering the entry than the buttons and we could do away with just
> > fg/bg.
> > 
> > If GtkStyle is to stay for easier compatibility, we still need
> > meaningful data in the GtkStyle struct, or we'll screw up any widget
> > external to GTK+ wanting text/base.
> 
> It's quite common for developers to use the wrong combination of colours
> (e.g. using text and bg together), so it would be great if they could be
> consolidated. If GtkStyle needs to stay for compatibility, maybe one of
> the colour pairs could be generated using some heuristics?

Not sure, provided we have a standard "entry" class, I guess we could
set text/base to the fg/bg colors of the style with such class enabled.

Cheers,
  Carlos