Re: Thoughts on GTK+ and CSS

[Tristan Van Berkom <tvb gnome org>]

On Mon, Aug 3, 2009 at 3:34 AM, Robert
Staudinger<robert staudinger gmail com> wrote:
> On Fri, Jul 31, 2009 at 7:28 PM, Tristan Van Berkom<tvb gnome org> wrote:
>
> [...]
[...]
>>
>> 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.
>
> Is that complexity really needed? Details below.
>
[...]
> HTML applies CSS on the DOM tree, thus positional pseudo classes like
> ":first-child" don't imply any semantics -- it's just the first
> element below the parent node. So I think it would be valid for
> containers that don't really have a notion of order (e.g. GtkFixed) to
> just match the first child of their internal list of children.

I think half of that complexity is certainly needed, and the other
half can be reliably introspected.

For instance:
  a.) I think its necessary for a customized composite widget author
       to be able to mark a vbox as an "itemized list", which directly
translates to:
       its wrong to assume a GtkBox contains an itemized list of
widgets, and its
       bad design to write code that tries to guess that information
by casing the
       types in the hierarchy.
  b.) I think its not important to specifically have the GtkBox mark the
       first or last child as "first" or "left" or "top", if the
positional information
       needed to layout the contents of a GtkBox can be introspected with
       consistent results.

Also, Christian suggested that we expose read-only child properties
specifically for use in the theme engine, this would work but IMO
would be equivalent to assigning some theme tag data to the
child widgets of a container, i.e. it would be code written in the
GtkContainer implementation dictating how the theme should
handle the child widgets.

Either way would work well, also, it would be possible to instead
introspect the packing at runtime reliably by listing the children
of a container and comparing their coordinates to eachother
relative to the parent container, thus deriving virtual row/column
information.

The problems I see with the current gtkrc/GtkStyle is only the
guesswork thats done on the classes directly, this causes apps
to be written more rigidly to cooperate with the theme and I also
think GTK+ application layouts can potentially be pretty complex and
definitely have needs that span beyond "every GtkEntry looks like this".

To fix these limitations I think its necessary to add a level of abstraction
across the board, that allows the application to define what is the style
to be used for a widget or container and also allows the theme to
define classes that suit an idea from a list of stock items that would
be required to implement the base GTK+ theme.

In an ideal world, only a composite/specialized widget would have some
theme data defined, and a GtkButton, GtkEntry or GtkComboBox would
always come out reliably naked and unthemed - unless a style has been explicitly
set for that widget, or unless you place the GtkButton in an "itemized list"
or a "dialog action area", the effect of adding a GtkEntry to a
"spreadsheet area"
might be different than the effect of setting a GtkEntry to be of the style
"urlbar" or "password".

Cheers,
           -Tristan