Re: GTK+ Theming improvements

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

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.

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.

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

On 8/29/07, Benjamin Berg <benjamin sipsolutions net> wrote:
> Hello,
>
> So here finally an E-Mail about the GTK+ theming discussion we had at
> the start of GUADEC and some things I picked up.
>
> In the discussion CSS had been mentioned a lot of times to a large
> extend because of the matching abilities that it has. It is possible to
> match on the hierarchy and also neighbours. Neighbour matching is
> impossible in GTK+ currently and it would with theming paddings between
> widgets. Also in CSS/HTML an item can have multiple classes.
>
> Here are some of the main points/ideas:
>       * Multiple themes in one application (eg. theme preview, glade)
>       * Instead of having the support directly in GTK+ create a common
>         library that can be used by Firefox, OpenOffice and maybe even
>         KDE/QT
>       * Don't use pixel sizes -- The maemo people designed the interface
>         in millimetre, however this is not that useful on a desktop
>         machine.
>       * Separating positioning of widgets out of the application, and
>         into the theme.
>       * No non-transparent X windows if possible
>       * 3D widgets, eg. lighting effects, or when rotating workspaces
>       * Solid animation support and transition effects. (imagine eg. an
>         animation when a menu item is activated, or handling an opening
>         expander)
>
> There is also http://live.gnome.org/GTK%2B/NewThemeApi (which needs to
> be updated) but I this is a pretty complete list.
>
> I think an interesting thing to discuss is the scope of any system. It
> was suggested that the theme should be able to handle large parts of the
> UI design. Other things that could be handled by themes include
> application graphics (eg. nautilus disk usage pie chart) or the metacity
> window frames.
>
>
> As a way forward it is important to know what a CSS based theme format
> might look like. Andreas Nilson has said he could help in this area.
> Other than this any ideas and comments are of course welcome.
>
> To help the overall process, I can try to keep the wiki in sync with any
> arguments that are brought up.
>
> Benjamin
>
> _______________________________________________
> gtk-devel-list mailing list
> gtk-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/gtk-devel-list
>
>
>