Re: Theming API Hackfest

["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.

>> Frankly, and this is also heavily influenced by the recent
>> gtk-css-engine work, I think nobody ever tried to push an engine to
>> the edge of what's actually possible.
>
> I do think that you are underestimating the work done by other people
> here. Look at the huge maemo theme. Look at the sugar theme, which while
> looking pretty simple has some interesting issues. Look at the
> Clearlooks engine and all its derivatives. Or maybe the the eXperience
> engine, a very powerful pixmap based engine that never took off ...
>
> There are probably a lot more examples that I do not know about.

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.

[...]

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].

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.

- Rob