Re: Thoughts on GTK+ and CSS

[Tristan Van Berkom <tvb gnome org>]

On Fri, Jul 31, 2009 at 4:15 AM, Robert
Staudinger<robert staudinger gmail com> wrote:
> On Thu, Jul 30, 2009 at 7:06 PM, Tristan Van Berkom<tvb gnome org> wrote:
>
> [...]
>
>> An example of the backwardness we have in place, is that,
>> IMO its simply wrong to assume the role of a GtkToolbar in a
>> given application, the toolbar already needs properties to override
>> theme settings in cases where its not in context. Another example
>> would be that you simply cant write a custom toolbar implementation
>> and inherit the theme of a toolbar unless you actually subclass the
>> GtkToolbar.
>
> This is a good point. The most natural mapping to CSS would probably
> be using a set of CSS classes [1] defined by gtk.
>
>> Then GTK+ could have a list of stock styles:
>>
>> #define GTK_STOCK_STYLE_MAIN_TOOLBAR      "gtk-stock-style-main-toolbar"
>
> Agreed (whatever the actual name). The theming would then go like
>
> GtkToolbar { ... } /* Common theming for all toolbars */
> GtkToolbar.gtk-stock-style-main-toolbar { ... } /* Additional theming
> for "main" toolbar. */
>
>> #define GTK_STOCK_STYLE_SMALL_BORDER      "gtk-stock-style-small-border"
>> #define GTK_STOCK_STYLE_LARGE_BORDER      "gtk-stock-style-large-border"
>
> Not sure what those would be for.

Maybe "indent" would be a better name than "border"; the idea is basically
to circumvent the possibility of boxes and tables comming up with any
undesired margins or indentations.

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.

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

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

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.

Cheers,
         -Tristan