On Sat, 2007-01-09 at 16:32 +0200, Mathias Hasselmann wrote:
> Why not use the most obvious solution for the problem: Keep the theming
> engine as is, but instead of using one single theming detail string,
> let's attach a theming class property in the spirit of CSS class names
> to widgets:
>
> const gchar** gtk_widget_get_style_classes (GtkWidget *widget);
>
> gboolean gtk_widget_has_style_class (GtkWidget *widget,
> const gchar *class_name);
>
> Well, or for optimal speed let's use GQuarks instead:
>
> const GQuark* gtk_widget_get_style_classes (GtkWidget *widget);
>
> gboolean gtk_widget_has_style_class (GtkWidget *widget,
> GQuark class_name);
>
> Now let's add the rule, that widgets have to provide a macro for each
> style class they define, and we even get some easy way to document style
> classes:
>
> #define GTK_STYLE_CLASS_TREE_VIEW_COLUMN_BUTTON \
> gtk_style_class_tree_view_column_button_get_quark ()
>
> You might argue defining quarks for this purpose is quite some effort,
> but Bugzilla and libegg contain the implementation of a G_DEFINE_QUARK,
> respectively EGG_DEFINE_QUARK marco declaring *_get_quark functions:
>
> G_DEFINE_QUARK (GtkStyleClassTreeViewColumnButton,
> gtk_style_class_tree_view_column_button);
>
> This approach might not be a big and final solution, but its an approach
> that can be implemented right now without breaking much stuff.
OK, this might solve some of the problems. But I see it much more
important to have the possibility of matching against these classes in
the gtkrc instead of an API for the engine to query them. Also I think
that applications need to be able to add attach their own classes to a
widget or removing ones that area already there. This is useful in
server cases:
* GtkComboBox can modify its classes to show if it is in
appears-as-list mode (it could be using an comboboxentry class
because it has a visible entry then).
* Custom widgets may want to look like eg. comboboxes, or fake
treeview headers. Adding classes is important for this.
In my opinion it is very important that any implementation like this
would right away have a complete set of classes. This is important as
theming is already a complex issue with a large set of special cases and
quirks, and adding more API will not make this better in the long run.
This of course does not (and cannot) address issues like:
* More complex layout support (eg. in the sugar theme widgets
should be aligned to a 15px grid most of the time.)
* Resolution independence
* For example notebook corner rounding (bug #457087). (Corners
should be rounded depending on the position of tabs)
Btw. I don't only want to discuss what can we do now to improve the
current situation in the 2.x cycle, but also how should theming could
look like in GTK+ 3.x. Both discussions are important though.
Benjamin
Attachment:
signature.asc
Description: This is a digitally signed message part