Re: gtk-style-context notes

[Carlos Garnacho <carlosg gnome org>]

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.

> 
> 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:
>  * 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().

Now that we are on that subject, I think it'd make sense pushing further
GtkStateFlags to replace GtkStateType, right now it's only used for
theming purposes, but having a gtk_widget_set_state_flags() would make
it really easy to trigger transition animations on the changed flags for
most of the cases, thoughts on that?

>  * Same for has_default

This is actually part of GtkRegionFlags, the modifiers passed when
creating a widget region, as I thought this is rather a positional
aspect of the widget than a state per se. A drawback of this approach is
that containers with a has_default child could need to add otherwise
unneeded region information.

It again requires hooking to the CSS parser by adding another symbol in
create_scanner() and updating parse_nth_child() to set that flag.

>  * probably more
> 
> The matching seems to be quite limited currently unfortunately. In most
> cases it should be good, but it is not possible to theme a button inside
> a (specific) notebook tab different to one inside the notebook page.

There is the GtkContainer::get_path_for_child() vmethod, container
widgets must implement this in order to return a specially constructed
GtkWidgetPath used for style matching, the default is to create a widget
path with no region info in between.

If the notebook did something like this:

static GtkWidgetPath *
gtk_notebook_get_path_for_child (GtkNotebook *notebook,
                                 GtkWidget   *child)
{
  GtkWidgetPath *path;
  gint tab_number;

  page_number = get_tab_number (notebook, child);
  path = gtk_widget_path_copy (gtk_widget_get_path (container));

  notebook_pos = gtk_widget_path_length (path) - 1;
  gtk_widget_path_iter_add_region (path, notebook_pos, "tab", 
                                   flags_for_tab_number (tab_number));
  return path;
}

Buttons inside notebook tabs could be styled in CSS through:

  GtkNotebook tab GtkButton { ... }
  GtkNotebook tab:nth-child(even) GtkButton { ... }

As opposed to any button inside a notebook:

  GtkNotebook GtkButton { ... }

Which would lose in specificity. So, this is supported, but needs
containers' love :). 

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

> 
> That is all I can think of right now.

Thanks a lot for the review!

> 
> I will probably start to commit some more intrusive changes to
> gtk-style-context (or if preferred a new branch).

Some help with containers and on defining a "standard" set of region and
class names would be great, if you're willing to get there :)

Cheers,
  Carlos