Re: Thoughts on GTK+ and CSS

[Alberto Ruiz <aruiz gnome org>]

2009/8/5 Robert Staudinger <robert staudinger gmail com>:
> On Tue, Aug 4, 2009 at 1:08 AM, Tristan Van Berkom<tvb gnome org> wrote:
>
> [...]
>
>> 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".
>
> It seems we are looking at the issues from a different angle.
>
> I think all gtk should do is expose a DOM that the future CSS
> subsystem can match against. Then there could be a gnome-hig.css that
> when loaded sets HIG compliant paddings and spacing like the standard
> group indent you mentioned.

I sort of agree here, I don't think we should support the full DOM API
though, just enough for CSS to do its job. On the other hand, anything
we do to represent an abstract scenegraph and poke properties could
potentially be shared by the accessibility bridge (gail) which would
be a big win IMHO.

>
> That would avoid putting semantics into gtk proper that are not
> applicable to all platforms (desktop, embedded, whatever) or might go
> stale in the future.
>
> - Rob
> _______________________________________________
> gtk-devel-list mailing list
> gtk-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/gtk-devel-list
>



-- 
Un saludo,
Alberto Ruiz