Re: Thoughts on GTK+ and CSS

[Robert Staudinger <robert staudinger gmail com>]

On Tue, Jul 28, 2009 at 3:40 AM, Keith Rarick<kr xph us> wrote:

[...]

> What you describe addresses the separation of semantic structure from
> presentation, but that approach is far more powerful if the semantic
> information is sufficiently rich and sufficiently general. Currently,
> writing a gtk theme feels like styling an html document made of
> nothing but div and span and some id attributes. I want it to feel
> like styling p, h1, nav, section, article, dl, blockquote, etc, with
> lots of useful classes too. Picking a next button by stock ID is too
> specific.
>
> For example, what if an app has a new group of related buttons, say
> "local view" and "remote view", not accounted for by existing themes
> that only pick buttons by their stock ID? There is no way to get the
> proper look for that group of buttons.
>
> Furthermore, how would a theme distinguish a solitary next button from
> one that is part of a prev/pause/next group? A theme might
> legitimately want those two next buttons to look different, but I
> don't see how it can be achieved reliably.
>
> Perhaps a "hints" property is flawed in detail, but I think the idea
> is sound. I advocate denoting *well-defined* but *generic* semantic
> structure.
>
> Here is roughly the reasoning I used for the "related" hint:
>
>  * A theme might want to display prev/pause/next buttons in a visually
> distinct group.
>  * A theme might also do that with icon/list/compact view buttons or
> back/forward buttons or some other as-yet-unknown set of buttons.
>  * What semantic properties do all of those examples share?
>  * They are all groups of buttons somehow related to one another in a
> meaningful way.
>  * This is a useful piece of information for themes.
>  * Unfortunately, there is currently no way to express this information.
>  * We should invent a way to denote this.
>
> I had similar lines of reasoning for the other example hints I listed.
> But maybe they should be handled on a case-by-case basis. Say, make up
> a new property for each one. I didn't suggest that because I thought
> it would have too much inertia. I want it to be easy for people to add
> new semantic structural information to apps -- the more the better!

I think gtk(-2.x) theming will always just be the icing on top of apps
that have to be well designed themselves. The hierarchy and ordering
inflicted by box widgets and friends is much more constrained than,
say, an HTML DOM.

To relate to your example of grouping prev/next/pause buttons in a
media player -- the way to do that would be writing
application-specific CSS that modifies a dialog precisely how you want
it to look. Pixel perfection just doesn't come "for free".

>> The "margin" property in gtk is not implemented like you assume above.
>> Also does GtkContainer not expose information about child widget
>> positions like you suggest using ":first-child" and friends. Work on
>> those limitations would break the way for more a more comprehensive
>> mapping of css onto gtk.
>
> Okay. I only meant that example to suggest what a theme could do in
> principle, even if it uses features that don't exist yet.
>
> Would you accept a patch with work toward those things, such as margin
> or first-child?

If there way a way to get the position of a child in a GtkContainer
(thus allowing for :first-child and other positional pseudo classes to
be implemented) that would make quite a difference in what you can do
with the css engine. I'm not in the position to make the call on gtk
patches though.

Best,
Rob