Re: Thoughts on GTK+ and CSS

[Tristan Van Berkom <tvb gnome org>]

Hi,
    I think its really exciting that you guys are working
on this, so I stole the time this morning to share in the fun...

I just want to throw out some ideas that Im sure are not new,
but I was surprised werent really addressed yet in this thread.

Im really not versed in what can/cant should/shouldnt be done
with CSS, so maybe my ideas are totally off mark in that regard,
other than that lets get into the juice ;-)

I think that the biggest problem with GtkStyle/gtkrc is that
we have been theming applications by widget class, I think
that if we are going to finally upgrade theming, this would
need to stop.

As Christian says, developers need to layout the spacing
of the application - and ofcourse - theme writers need to
augment/change the palette used to space the application etc.

An example of the backwardness we have in place, is that,
IMO its simply wrong to assume the role of a GtkToolbar in a
given application, the toolbar already needs properties to override
theme settings in cases where its not in context. Another example
would be that you simply cant write a custom toolbar implementation
and inherit the theme of a toolbar unless you actually subclass the
GtkToolbar.

Heres a vague outline of a relatively simple implementation that
would get the job done, it would be up to the CSS gods to decide
if it were "right", but it would get the job done.

Like any solution to a feature we never implemented before, we would
have to add API:

void gtk_widget_add_style (GtkWidget *widget, const gchar *style_id);

A style would ofcourse cascade through the widget hierarchy, so adding
a style to a container would effect all the children.

Then GTK+ could have a list of stock styles:

#define GTK_STOCK_STYLE_MAIN_TOOLBAR      "gtk-stock-style-main-toolbar"
#define GTK_STOCK_STYLE_DIALOG_MAIN_AREA  "gtk-stock-style-main-toolbar"
#define GTK_STOCK_STYLE_SMALL_BORDER      "gtk-stock-style-small-border"
#define GTK_STOCK_STYLE_LARGE_BORDER      "gtk-stock-style-large-border"
#define GTK_STOCK_STYLE_FIRST_ITEM        "gtk-stock-style-first-item"
#define GTK_STOCK_STYLE_LAST_ITEM         "gtk-stock-style-last-item"
(the details of this list would be a lengthly review process and probably
as such represents the most work in this hypothetical implementation)
...

Applications that are well themable would be discouraged from
using GTK+ apis that effect the spacing directly, developers would
be encouraged to use symbolic styles to define the look of thier
applications.

On the CSS side things would look almost the same, you
would define style properties per widget class inside a specified
tag (or style name), so all buttons defined inside a "first-item" tag
would recieve the "first-item" GtkButtonClass sugar.

And ofcourse, customized applications that use thier own CSS can derive
elements from the theme and use style definitions that arent defined
in the GTK+ stock list.

Oh yeah, backwards compatability, well we could leave in the theming
widgets by class name only and slowly migrate, theres not much
to break anyway, just a hope to offer real theming capabilities in
the future.

Anyway that was my take, I hope its useful ;-)

Cheers,
        -Tristan

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
>