Re: Thoughts on GTK+ and CSS

[Christian Dywan <christian lanedo com>]

Am Fri, 31 Jul 2009 13:28:02 -0400
schrieb Tristan Van Berkom <tvb gnome org>:

> On Fri, Jul 31, 2009 at 12:47 PM, Robert
> Staudinger<robert staudinger gmail com> wrote:
> > 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
> 
> Ofcourse, great example - the way I would suggest implementing this is
>    a.) we recognize the need to show itemized groups
>    b.) we define GTK_STOCK_STYLE_ITEM_GROUP
>    c.) we allow some customized containers define themselves as
> itemized groups:
>       - Base container classes would not be itemized groups, this
> would obstruct the programmer
>       - Classes like GtkButtonBox for instance could be an itemized
> group - or GtkMenuShell
>       - Classes that define themselves or their children as styled
> widgets are always higher level
>         composite widgets or special purpose widgets.
> 
> Then, the implemented CSS style for an item group would also cover
> GtkBox, allowing
> GtkBox to be styled as an itemized group, but not be one by nature,
> allowing programmers
> to implement their own treeviews and column headers for example - and
> still leverage
> the itemized group definitions from the theme.
> 
> [...]
> >> 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; }
> >
> 
> Sounds awesome.
> 
> >> 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 { ... }
> >
> 
> Also awesome :)
> 
> >
> > 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.
> 
> Is it important that the CSS subsystem have this data directly from
> GtkContainer ?
> 
> For instance, there really is not many classes with positional data;
> and the positional data can vary depending on the container type,
> GtkBin doesnt have positional data - so would it represent much work
> to handle the "position" data only for GtkBox, GtkMenuShell and
> GtkToolBar instead of on the GtkContainer ?
> 
> I would also expect that the nature of what the CSS subsystem is doing
> with a GtkTable is going to be all together different, and you
> probably wont want a position at all (i.e. you might want to know all
> the widgets that are on top, or on the left), and the position of a
> page in a notebook is well, entirely different ;-)
> 
> I really have no idea how the css subsystem is implemented and I am
> probably overlooking some things; only it seems to me, if only for the
> sake of OO purity and api clarity; that the "position" property
> doesnt really mean anything for the GtkContainer class itself.

I suspect the CSS will not want to special case each type of container
in GTK+, let alone third party libraries and applications. So
implementing a notion of positioning has to be at the GtkContainer
level.

ciao,
    Christian