Re: Theming API Hackfest

["Alberto Ruiz" <aruiz gnome org>]

2008/9/3 Robert Staudinger <robert staudinger gmail com>:
> On Fri, Aug 29, 2008 at 6:13 PM, Benjamin Berg
> <benjamin sipsolutions net> wrote:
>
> [...]
>
>>> Here's what I learned so far:
>>> - The biggest issue is the impedance mismatch between configuring
>>> widget style properties in gtkrc while engines are built around
>>> drawing primitives.
>>
>> Not quite sure what you mean here exactly.
>
> Two issues:
>
> (1) The gtk/engine interface allows for implicit styling by the
> engine. It is possible to write a fancy engine that just uses a 3 line
> boilerplate gtkrc loading the engine library. Of course this breaks
> toolkits that try to look like gtk using gtk_rc_get_style_by_paths().
>
> (2) Gtkrc talks about widgets but engines draw primitives. E.g. a
> GtkNotebook is drawn using "box_gap" and "extender" primitives.
> However, there is no vocabulary in gtkrc to configure primitives.
>
> [...] (There are of course dusty corners)
>
>>> - Detail strings are not the problem they're sometimes made to be.
>>
>> Detail strings are part of the problem. I see two important flaws with
>> the current detail strings. The first one is that they are fixed and
>> cannot be extended easily because of API compatibility. The second one
>> is that there are a lot of inconsistencies in their naming.
>> As an example for this look at the different style properties that only
>> exists to add more information to detail strings. Or look at the two
>> scrollbars and scales. One calls the slider "[hv]scale" the other
>> "slider". And guess what? The scrollbar calls the stepper buttons
>> "[hv]scrollbar".
>>
>> Both of these make it harder to create good themes. One needs to shift
>> trough a lot of style properties and learn the different quirks of
>> widgets -- often by reading the GTK+ source code.
>
> Thinking again, most of the detail strings are actually redundant if
> the engine is allowed to know what kind of widget is drawn.

No, they are not always redundant, and the engine is allowed actually.
That approach (which is quite used), suddenly ties engines to
implementation details of widgets, denying developers to change those
implementations since the theming API is a public interface that
people consume to make third party engines.

Now, the idea discussed is to solve that by allowing widgets to give
more information without allowing engines to crawl up over the
widget's parents and stuff like that.

> I did not mean to say that there are great engines out there or that
> they weren't a lot of work, just that the internal gtk/engine
> interface is way more powerful that what most engines expose.

Powerful in this case is an enemy of maintenable code I'm afraid.

> To sum up, here is what I'm prototyping:
> - Use CSS vocabulary to match all widgets and primitives.
> - Only what is specified in CSS is drawn, nothing is implicit or
> special-cased inside the engine.
> - Feed back gtkrc snippets created from CSS to support
> gtk_rc_get_style_by_paths() [future].

It is actually a quite valuable work that people start playing with
more usable engines for artists and i'm pretty sure as soon the idea
progress you would be able to give us a quite valuable feedback.

> Generally, instead of passing more context information to the engine
> as it is being discussed, I'd rather provide hooks to the style
> matching subsystem for widget implementers and look mimicking. This is
> also the approach taken in the CSS engine.

You mean hooks as in "widget: If I match this style matching
expression I send this event" or something like that?

Could you elaborate a little bit on how this could be implemented and
how much effort for a widget implementer would take to do it properly?


-- 
Cheers,
Alberto Ruiz