Project

General

Profile

Bug #336

[PATCH]: Fix skinned ui not being drawn properly with gtk-3 >= 3.9

Added by Hans de Goede over 10 years ago. Updated over 10 years ago.

Status:
Closed
Priority:
Major
Assignee:
-
Category:
plugins/skins
Target version:
Start date:
August 27, 2013
Due date:
% Done:

100%

Estimated time:
Affects version:

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.

0001-skins-Properly-propagate-draws.patch (1.74 KB) 0001-skins-Properly-propagate-draws.patch [PATCH] skins: Properly propagate draws Hans de Goede, August 27, 2013 09:24

History

#1 Updated by John Lindgren over 10 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.

https://github.com/audacious-media-player/audacious-plugins/commit/2a43c567fec21b34825869ce10d68277c4361097

#2 Updated by John Lindgren over 10 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 over 10 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 over 10 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.

Also available in: Atom PDF