Bug #336
[PATCH]: Fix skinned ui not being drawn properly with gtk-3 >= 3.9
100%
Description
gtk only guarantees expose events / emitting the draw signal for widgets which are backed by a native (ie X11) window, and the various GtkDrawingArea widgets the skinned ui uses are not backed by a native window.
For non native window backed widgets, it is up to the parent / container which does have a native window to propagate the draws. This means that when audacious connects to the draw signal of the GtkWindow-s it uses, overriding the default handler, it must propagate the draw to its children.
So far audacious has been getting away with not doing this since gtk was handling sending expose events with a shotgun approach sending them to all children of an exposed widget unconditionally. This has been fixed in gtk 3.9.x / 3.10, which causes the audacious skinned ui to only draw the window background, and nothing else, this patch fixes this.
History
#1 Updated by John Lindgren about 11 years ago
- Status changed from New to Closed
I think the more proper fix is to return FALSE from our draw functions, letting GTK+ propagate the signal. Then, we use gtk_widget_set_app_paintable() to keep GTK+ from drawing the default window background.
#2 Updated by John Lindgren about 11 years ago
- Target version set to 3.4.1
- % Done changed from 0 to 100
- Affects version 3.4 added
#3 Updated by Hans de Goede about 11 years ago
I can confirm that the committed fix also fixes the skinned ui drawing issues with gtk-master.
When looking at the patch I noticed that it changes the return value for all draw handlers in the skinned ui. Would it not be better to have a new DRAW_FUNC_END_FALSE macro, and use that to end window_draw, and keep the other draw function returning TRUE ?
Note I'm not seeing any adverse side-effects of the current solution.
#4 Updated by John Lindgren about 11 years ago
For GtkDrawingArea, I don't think it matters whether we return TRUE or FALSE since GTK+ doesn't do any further processing. I favor FALSE if only because it's consistent with e.g. GtkWindow. Unfortunately the GTK+ docs don't provide any guidance here.