Theming API Hackfest

[Alberto Ruiz-4]

Hello board!

during last GUADEC we had a theming API hackfest and we came up to the
conclusion that there's need for some serious work regarding how Gtk+
handles themes to make the theming code more flexible and maintenable.
However, any changes would require a breakage in the current ABI/API
and consequently most engines would need some rework so we want to
come up with something before Gtk+ 2.90/3.0 that can be discussed for
inclusion.

Benjaming Berg and myself were really interested in this (plus Cody
Russel has expressed his interest to join the effort as well) and we
discussed the idea of having a dedicated hackfest soon so that we can
come up with a proposal.

The goals would be:

1) Allow widgets to pass on more contextual information to theme
engines so that engines don't have to mess with widget implementation
details
2) Improve the theming api so that engines for native platforms
(Windows, Mac) are easier to write and maintain
3) Came up with a proper API for better third party toolkit
integration (XUL, Java, Qt)
4) Evaluate if an API backwards compatibility layer is possible to not
break engines

I would like to propose a hackfest on late January/2009 hosted at
Dublin in the Sun offices. Sun can provide the venue which has plenty
of materials to host the hackfest (projectors, whiteboards, printers a
canteen) and the local organization as long as we keep it a small
hackfest (around 5 people). The expenses for people needed for
sponsorship would be covered by the foundation though since we don't
have budget for that.

I would like to request feedback from the board and the Gtk+ team
regarding the idea. I can be present on the next Gtk+ IRC meeting if
you would like to discuss it in the next agenda.

--
Cheers,
Alberto Ruiz
_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@...
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

[Robert Staudinger]

Hello,

while this email is probably not primarily about technical issues, here goes ...

On Thu, Aug 28, 2008 at 3:38 PM, Alberto Ruiz <aruiz@...> wrote:
> Hello board!
>
> during last GUADEC we had a theming API hackfest and we came up to the
> conclusion that there's need for some serious work regarding how Gtk+
> handles themes to make the theming code more flexible and maintenable.
> However, any changes would require a breakage in the current ABI/API
> and consequently most engines would need some rework so we want to
> come up with something before Gtk+ 2.90/3.0 that can be discussed for
> inclusion.

While working on the gtk-css-engine for the last couple of weeks I've
had some discussions with Benjamin Berg regarding the theming issues.
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.
- Being able to match against widgets (and their hierarchy) is
immensely powerful, possibly essential, for the CSS engine.
- Detail strings are not the problem they're sometimes made to be.

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. It would be less than optimal if
things were changed and we'd end up with a less powerful API than we
have now. The current gtk/engine interface is amazingly versatile.
I'll hopefully be able to provide more detail within a few weeks, when
back from holiday.

Best,
Rob
_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@...
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

[Brian Cameron]

Alberto:

I give a +1, but I think there should be another goal.  To invest some
attention to the accessibility themes, like HighContrast and perhaps
helping to develop an effort to resolve the issues there.  How can we
take things to the next level for a11y?

Also the ability to run the computer in black/white (or other two color
combinations for people with color blindness issues - I think KDE is
working on something like this).  It would be good to make sure we don't
forget to include ways to improve desktop usability for people with
disabilities when we consider how to rewrite theming engines.

I'm sure there are other examples.

Brian

> during last GUADEC we had a theming API hackfest and we came up to the
> conclusion that there's need for some serious work regarding how Gtk+
> handles themes to make the theming code more flexible and maintenable.
> However, any changes would require a breakage in the current ABI/API
> and consequently most engines would need some rework so we want to
> come up with something before Gtk+ 2.90/3.0 that can be discussed for
> inclusion.
>
> Benjaming Berg and myself were really interested in this (plus Cody
> Russel has expressed his interest to join the effort as well) and we
> discussed the idea of having a dedicated hackfest soon so that we can
> come up with a proposal.
>
> The goals would be:
>
> 1) Allow widgets to pass on more contextual information to theme
> engines so that engines don't have to mess with widget implementation
> details
> 2) Improve the theming api so that engines for native platforms
> (Windows, Mac) are easier to write and maintain
> 3) Came up with a proper API for better third party toolkit
> integration (XUL, Java, Qt)
> 4) Evaluate if an API backwards compatibility layer is possible to not
> break engines
>
> I would like to propose a hackfest on late January/2009 hosted at
> Dublin in the Sun offices. Sun can provide the venue which has plenty
> of materials to host the hackfest (projectors, whiteboards, printers a
> canteen) and the local organization as long as we keep it a small
> hackfest (around 5 people). The expenses for people needed for
> sponsorship would be covered by the foundation though since we don't
> have budget for that.
>
> I would like to request feedback from the board and the Gtk+ team
> regarding the idea. I can be present on the next Gtk+ IRC meeting if
> you would like to discuss it in the next agenda.
>

_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@...
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

[Alberto Ruiz-4]

2008/8/29 Brian Cameron <Brian.Cameron@...>:
>
> Alberto:
>
> I give a +1, but I think there should be another goal.  To invest some
> attention to the accessibility themes, like HighContrast and perhaps
> helping to develop an effort to resolve the issues there.  How can we
> take things to the next level for a11y?

> Also the ability to run the computer in black/white (or other two color
> combinations for people with color blindness issues - I think KDE is
> working on something like this).  It would be good to make sure we don't
> forget to include ways to improve desktop usability for people with
> disabilities when we consider how to rewrite theming engines.

That's actually a good point. The idea is that we will bring people
from other toolkits to have a few "feedback days/sessions" and then
concentrate our work taking their input into account. Adding a11y to
the agenda makes a lot of sense to me.

However, any of the people willing to attend has any kind of
experience there. Can you think of anyone with expertise enough that
have dealed with Gtk+ themes for this matter?

> I'm sure there are other examples.
>
> Brian


--
Cheers,
Alberto Ruiz
_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@...
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

[Benjamin Berg]

Hello,

On Thu, 2008-08-28 at 21:33 +0200, Robert Staudinger wrote:
> While working on the gtk-css-engine for the last couple of weeks I've
> had some discussions with Benjamin Berg regarding the theming issues.

Well, lets argue some more ;-)

> 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.
There are some issues for native themes, as these need to set a lot of
style properties to get the sizing right. But the only way to do this is
to parse gtkrc snippets. I do not see a big problem for "normal" GTK+
themes though.

> - Being able to match against widgets (and their hierarchy) is
> immensely powerful, possibly essential, for the CSS engine.

It is powerful. And the current stuff is pretty good. But there are some
fundamental issues with the current approach.
As an example, the matches needed to get the font color right for
buttons in the sugar theme:

  widget_class "*<GtkButton>*"           style "button"
  widget_class "*<GtkCheckButton>*"      style "checkbutton"

Yes, the "checkbutton" style is essential here. Because it needs to
revert (!) the color changes from the "button" style. To do this some
code in the engine is needed. And all this falls over as soon as one
application sets the "draw-indicator" property on a checkbutton to
FALSE ...

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

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

> It would be less than optimal if
> things were changed and we'd end up with a less powerful API than we
> have now. The current gtk/engine interface is amazingly versatile.
> I'll hopefully be able to provide more detail within a few weeks, when
> back from holiday.

Yes, you can add features by adding style properties. Yes the engine can
access the widget and do all kinds of things based on that. However, I
ask myself if all this power is really useful if it is not even
documented. And some things in the engine can again create problems for
applications.
The reason for this is that it is not only GTK+ that uses the themes and
engines. There are custom widgets, that should like normal GTK+ widgets.
There is the work to integrate other widget sets with GTK+ (xulrunner,
OOo, QT and many more).

As an example, here are the steps that one would need to go trough to
properly fake a treeview header (not fully checked, but should be about
right):

     1. Create a GtkTreeView
     2. Create a GtkTreeViewColumn
     3. Make sure everything is realized (ie. it needs to be in some
        window and stuff)
     4. Then get the button widget with gtk_tree_view_column_get_widget.
     5. Use this widget (and its style) to pass over to gtk_paint_box,
        etc.
     6. Replicate the buttons border calculation so those are correct.
     7. The theme may switch and stuff, so connect to the buttons
        style-set signal.
     8. Repeat the GtkTreeViewColumn setup so that you have three
        columns. That way Clearlooks can do its special casing for the
        first and last column.

Some of these steps are only necessary because the engines (need to) use
the real widget to figure out the column position.

Well, enough for now.

Benjamin


_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@...
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

[Brian Cameron]

Alberto:

> That's actually a good point. The idea is that we will bring people
> from other toolkits to have a few "feedback days/sessions" and then
> concentrate our work taking their input into account. Adding a11y to
> the agenda makes a lot of sense to me.
>
> However, any of the people willing to attend has any kind of
> experience there. Can you think of anyone with expertise enough that
> have dealed with Gtk+ themes for this matter?

Peter.Korn@... or Willie.Walker@... would probably be the two
people I would contact.  They would be able to recommend the best people
who could attend.  Peter is involved with Java a11y and has a lot of
real world experience with the needs of accessibility users.  Giving
input from how this is done in Java might also be of value.  It might
also be useful to have someone with a usability background there, such
as Calum.Benson@....

Most of my a11y contacts are in Sun, and Sun has been involved a lot
with a11y.  However, I'm sure there are also people at Red Hat or
Ubuntu or other places who are involved with a11y and might be
interested.  It might be good to also send an email to the
gnome-accessibility-devel@... list and see who is interested and
has the skills to help you.

Brian


_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@...
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

[Robert Staudinger]

On Fri, Aug 29, 2008 at 6:13 PM, Benjamin Berg
<benjamin@...> 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
_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@...
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

[Alberto Ruiz-4]

2008/9/3 Robert Staudinger <robert.staudinger@...>:

> On Fri, Aug 29, 2008 at 6:13 PM, Benjamin Berg
> <benjamin@...> 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
_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@...
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

[Robert Staudinger]

On Wed, Sep 3, 2008 at 1:25 PM, Alberto Ruiz <aruiz@...> wrote:

[...]

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

I did not say /all/ detail strings are redundant, but if the redundant
ones were removed it might be easier to find a solution avoiding the
quirks of a string API for the remaining ones.

Also I thought this whole thread was about theming in gtk3, for which
it was proposed that direct access to widgets should be revoked. In
gtk2 it's a different story, as we all know ...

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

My point is that permitting to traverse the widget tree allows for
simpler and more generic code in gtk proper. gtk_widget_get_parent()
is already there, nothing new required. See below for details.

[...]

> 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?

The CSS engine fills a vtable, so the selection engine can traverse
the widget hierarchy without actually knowing anything about widgets.
Look for `ccd_node_class_t' in the file linked below. Lookalike
toolkits could fill the vtable with their own functions, thus being
able to fake entire widget hierarchies without creating any gtk widget
offscreen to have it drawn correctly.

http://bzr-playground.gnome.org/~robsta/gtk-css-engine/annotate/54?file_id=ccdnode.h-20080812073847-d210lox1qul689g2-44
_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@...
http://mail.gnome.org/mailman/listinfo/gtk-devel-list