Re: GTK+ Theming improvements

["Lieven van der Heide" <lievenvanderheide gmail com>]

On 9/1/07, Benjamin Berg <benjamin sipsolutions net> wrote:
> On Fri, 2007-31-08 at 13:26 +0200, Lieven van der Heide wrote:
> > As for the general rendering of widgets, I think the current way of
> > letting the widget itself do the drawing, using a bunch of primitives
> > (ie. boxes, frames, etc.), and then letting the theme engines theme
> > just those primitives, instead of the whole widget, has shown to not
> > really work. What most theme engines seem to be doing now, is kind of
> > reverse engeneer those draw calls, and then render the theming in
> > their own way, which often is quite different from what the widget
> > actually thought is was drawing.
>
> Most of the time these are special cases as for example making certain
> corners rounded, but true.
>
> > I think it would be better if each widget just has it's own, specific
> > rendering class, which has a single function that should render the
> > complete widget at once. (this way, you kind of get a model/view
> > seperation inside controls). Themes can then override this rendering
> > class, and have complete freedom inside the render function of that
> > rendering class.
>
> This sounds a lot like how QT works (I have not had a very deep look
> though). However I don't think that any system should require build time
> linking. As desktop environments (GNOME, maemo) and/or applications will
> need custom widgets.

I don't really get what you mean with build time linking.

Custom widgets are perfectly possible with this approach. Even more so
than with the current approach. The thing is that the rendering
classes can query any other renderer of other widgets, to which they
forward their rendering. If you for example make a widget that's much
like a treeview, you should still make a specific renderer for that
widget, but make a default implementation that just forwards
everything to the treeview renderer. If a theme does not implement
this new widgets renderer, but it does implement the treeview
renderer, then the theming will still look good on both the treeview,
and on this new widget. If a theme engine decides that it does want to
have separate theming, it can implement the renderer of that new
widget, and render it in a different way completely.

> This is a general problem that I have not brought up earlier. But I
> wonder how to handle one widget that may have two different modes. An
> example that is annoying me right now is the radiobutton. It can not
> only be a drawn as normal radio button with an indicator, but also as a
> button without an indicator (in eg. GtkRadioToolButton).
> In the two different cases you may not only want to have some different
> style for the radiobutton, but also for the widgets (label) inside. I
> think that we either need to remove any case like this, have the
> possibility to style widgets (and their children) based on properties or
> need a second independent representation of the UI for theming.
>
> Hm, I don't see a way right now to handle the connected buttons in a
> button box with this approach nicely.
> http://futurepast.free.fr/buttonbox.png

I think that's pretty much orthogonal to it. It will not solve it, but
it won't prohibit us from using something like that css system for it.
The thing that that css system could do, is to just select the
appropriate renderer, using the appropriate settings, depending on the
widget that's being rendered, and the surroundings of that widget.
Note that a single theme engine can have multiple implementations of
the same renderer class (ie. it can have two button renderers). The
css system can then pick a different renderer if the button is for
example neighboring another button.

>
> > Each renderer should also have a default implementation, which renders
> > the widget in a default way, using lower level rendering classes,
> > which render things like edges and boxes. If a theme engine doesn't
> > implement a specific widget's rendering class, but it did implement
> > the lower level ones, then it will still be rendered using something
> > that fits your theme (basically in the same way it's supposed to work
> > now).
> >
> > It should also be possible for a renderer to use the renderer of
> > another (more basic) widget ,for example, a treeview could use the
> > button renderer as the default renderer for it's column headers.
> >
> > pseudo code for the default renderer of a checkbox:
> >
> > class CheckBoxRenderer
> > {
> >   struct Params_s
> >   {
> >     int state;
> >     string label;
> >   }
> >
> >   virtual void render(GdkDrawable target,Params_s params)
> >   {
> >     // default implementation that uses the generic renderer
> >     GenericRenderer generic_renderer = get_renderer(GENERIC_RENDERER);
> >     generic_renderer.render_box(target,Rect(0,0,16,16));
> >
> >     if(params.state)
> >     {
> >        generic_renderer.draw_check(target,Rect(0,0,16,16));
> >     }
> >
> >     generic_renderer.draw_text(target,Point(24,0),params.label);
> >   }
> > }
> >
> > In this example, overriding the generic renderer class will let you do
> > theming in the way it's done right now, overriding the
> > CheckBoxRenderer will give you complete freedom over the way you want
> > to render the checkbox
> >
> > To still be able to set up some generic theming things, that will be used by
>
> Something missing here?
>
>
> Benjamin
>
>