Re: Thoughts on GTK+ and CSS

[Tristan Van Berkom <tvb gnome org>]

On Wed, Aug 5, 2009 at 12:09 PM, Robert
Staudinger<robert staudinger gmail com> wrote:
[...]
> It seems we are looking at the issues from a different angle.

Yes, which is why I am still here :)

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

I already expressed it enough that the only thing I think that can save
us from unpredictable results, is a clean set of semantics for it.

When I look at HTML, there is text and images and dividers, the CSS
doesnt assume anything about the HTML elements by virtue of
them being a piece of text, or an image embedded in text - its always
done by strictly making an association to a class in the css file;
i.e. h1,h2 etc.

GTK+ is a much richer set of screen elements than just text, images
and dividers - the widget classes themselves can be comparable to
the elements you can find in an HTML document, the only thing missing
here is only the symbolic "h1/h2" etc semantics needed to complete the
circle, i.e. transmit to the theme what was intended to be done with
"this text" or "this image".

Without any semantics to be use to transmit the intent of the application
writer, how do propose to actually implement the casing code that decides
what GtkBox is an itemized list ?

Will you just assume that buttons inside a GtkBox are itemized ?

What if there are intermediate alignments ?

What if I have a GtkVBox { GtkMenuBar, GtkTable, GtkButton }, will
my button have an accidental rounded bottom ?

Im very curious about how the theme engine is at all expected to
operate without any hinting.

Regards,
          -Tristan