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
Attachment:
signature.asc
Description: This is a digitally signed message part