Re: Thoughts on GTK+ and CSS

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

Cheers,
          -Tristan