Re: Thoughts on GTK+ and CSS

[Tristan Van Berkom <tvb gnome org>]

On Tue, Jul 28, 2009 at 2:45 AM, Robert
Staudinger<robert staudinger gmail com> wrote:
> 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
> _______________________________________________
> gtk-devel-list mailing list
> gtk-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/gtk-devel-list
>