On 09/28/2010 07:28 AM, hermann wrote:
Am Montag, den 27.09.2010, 16:57 +0200 schrieb Olivier
Guilyardi:
My point was that widgets drawn directly with
Cairo bypass the
gtk_paint_*()
drawing abstraction layer, which would forbid engine to provide their
own knob
drawing implementation, as it's done for buttons, etc...
Therefore, such Cairo-based knobs wouldn't support the full GTK
theming
capabilities.
In Gtk+3 many GDK functions are replaced by cairo.
gtk_widget_draw() will take any cairo surface then.
http://live.gnome.org/GnomeGoals/GTKRenderingCleanup
Okay, it says "All GtkStyle drawing functions (gtk_paint_box(), etc) have been
changed to take a #cairo_t instead of a window and a clip area. ::draw
implementations will usually just use the cairo context that has been passed in
for this."
I'm not a gtk engine wizard, but the problem is still here IIUC.
If you draw directly with Cairo within your widget, your bypass the drawing
"driver" layer, for example used by ClearLooks which overloads the old
gtk_draw_*() functions in clearlooks_style_class_init():
http://clearlooks.cvs.sourceforge.net/viewvc/clearlooks/clearlooks/src/clea…
Whether gtk or a specific engine draw internally with Cairo or not doesn't
change the situation.
I suppose that the only solution would be to add some knob drawing primitives to
the GtkStyle class itself. That would allow gtk engines developers to provide
their own knob drawing implementation, and also separate the rendering code from
the knob logic.
But that might be a lot of trouble.
--
Olivier