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