Re: Thoughts on GTK+ and CSS

[Robert Staudinger <robert staudinger gmail com>]

On Fri, Jul 31, 2009 at 6:19 PM, Tristan Van Berkom<tvb gnome org> wrote:

[...]

> The idea of theme writers doing something to the first or last item
> of a GtkBox simply based on it being a GtkBox; is a scary idea to me,
> while I do recognize the value of exposing the positional data of GtkBox
> to the theme code - ideally though - the theme code should never ever do
> anything to the interface that the interface didnt ask for (i.e. the
> theme engine
> only applies CSS classes to widgets that set a tag for that class, or possibly
> default to a tag, leaving programmers with expectable results, always),
> unfortunately we have to include some level of support for this in order to
> transition away from old broken themes that make direct assumptions
> about your widget classes.

People frequently request being able to round only the outer buttons
of button boxes or treeview headers, like so:
http://www.gnome.org/~robsta/tmp/child-index-selector.png

> So, small/medium/large indentations for instance, could be done something
> more like this:
>
> /* GtkBox theming for large indentations */
> gtk-stock-style-indent-large.GtkBox { indent first widget by X pixels }
>
> /* GtkTable theming for large indentations */
> gtk-stock-style-indent-large.GtkTable { indent widget at first
> column/row by X pixels }
>
> I even wonder if the CSS code could be scoped and look more clear:
>
> /* theming for large indentations */
> gtk-stock-style-indent-large {
>    GtkBox { indent first widget by X pixels }
>    GtkTable { indent widget at first column/row by X pixels }
> }

That wouldn't work, but in an ideal world you would get away with something like

    .gtk-stock-style-indent-large { margin-left: 12px; }

> This approach would make it more clear, that its the tables and boxes
> that appear in the "indent-large" tag that we are theming, the other
> way around makes it look like theming widgets hardcoded by class is
> standard and that "gtk-stock-style-main-toolbar" is some kind of special
> case only for toolbars (for instance, a theme that handles toolbars might
> effect toolitems or even theoretically menuitems in the main toolbar by
> virtue of being in the "main-toolbar" tag, the fact that there is a GtkToolbar
> instance in the "main-toolbar" area is only a detail).

A toolbar item in the main toolbar would be addressed like

    .gtk-stock-style-main-toolbar GtkToolItem { ... }

> The design we need makes a clean separation between the application
> and the theme, the theme is like a hypothetical palette of symbolic
> names that needs to eventually cover all of our needs, every time the theme
> modifies a widget - it has to be because the application developer intended
> the theme to modify it in some way (GtkDialogs and other composite widgets
> would setup indentations and other spacing tags from the theme onto its
> internal children instead of setting up spacing pixels directly).
>
> Also, about exposing the position in GtkContainer, personally I think
> "position" should stay a detail of GtkBox, GtkMenuShell, GtkToolBar,
> I think that when accessing the position of a GtkTable its best to use
> the row/column - not sure if/how "position" can just make sense or
> be useful on just any container.

A container that has no notion of position (maybe like GtkFixed) could
return -1 for each child, so the CSS subsystem would know to ignore it
and not apply any positional selectors like ":first-child" and
friends.

- Rob