Re: Theming API hackfest: last call

[Christian Dywan <christian imendio com>]

Am Wed, 15 Oct 2008 13:48:47 +0200
schrieb "Robert Staudinger" <robert staudinger gmail com>:

> On Wed, Oct 15, 2008 at 12:03 PM, Christian Dywan
> <christian imendio com> wrote:
> 
> [...]
> 
> > Sounds like it would make subclassing kind of hard, if I understand
> > you right. For instance people like to subclass to create all sorts
> > of buttons and it is only intuitive that they all look similar.
> > What would happen to my hypothetical ExampleSelectColorButton if
> > the GtkButton styles are not applied to it?
> 
> It's not so much about picking the one or the other way, but providing
> both possibilities. The general case will likely be styling on the
> type name, but in rare cases implicit style inheritance may not be
> desired. Imagine (ok, this is somewhat contrieved) that window
> decorations will be drawn by gtk itself, and designers will just style
> GtkWindow to their liking. It is conceivable that this styling should
> not be inherited to GtkPlug, so ".GtkWindow { ... }" would be the way
> to go.
> 
> Relatedly I am thinking of a sane way to import styling into CSS
> blocks to aid widget mimicking. Imagine you want to mimick a GtkButton
> with your own wonderful implementation "FooButton", but unrelated in
> the GType hierarchy (not inheriting from GtkButton). Something like
> this might aid to apply GtkButton styling:
> 
> FooButton {
>     ccss: import(GtkButton);
> }
> 
> Analogously, from the GtkWindow example above, it would be possible to
> apply styling from GtkWindow to GtkDialog (it would not apply
> implicitly, because we want to avoid styling GtkPlug). And let's make
> up some additional properties as well:
> 
> GtkDialog {
>     ccss: import(.GtkWindow);
>     minimize-button: none;
>     maximize-button: none;
> }
> 
> All this is of course pretty premature, but I hope the idea is clear.

Hey,

thanks for the explanation. I see the idea and I agree, automatic
inheritance doesn't always make sense. However as seem to suggest to
add explicit rules to the theme's gtkrc. I think if we are taking this
route, there must be a way to do this on the implementation side of the
FooButton class. Otherwise any new widget that is supposed to render
like a button will be unusable, design/ usability wise, until each
theme is update to be aware of the new widget.
So, unless that was your intent anyway, I'd suggest we need some way to
implement that relationship of GtkButton and FooButton in the new
widget. This might be a mere style property, or it could be inside a
gtkrc or css file that the new widget is providing.

ciao,
    Christian