After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 752599 - GtkDrawingArea: Only respects background-color if "draw" signal is unconnected
GtkDrawingArea: Only respects background-color if "draw" signal is unconnected
Status: RESOLVED FIXED
Product: gtk+
Classification: Platform
Component: Widget: Other
3.17.x
Other Linux
: Normal normal
: ---
Assigned To: gtk-bugs
gtk-bugs
Depends on:
Blocks:
 
 
Reported: 2015-07-19 19:36 UTC by Felix Riemann
Modified: 2017-05-25 19:32 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
sample code showing the different behaviours (779 bytes, text/plain)
2015-07-19 19:36 UTC, Felix Riemann
  Details
Revert "drawingarea: checks parent's draw() before call it" (1.02 KB, patch)
2015-07-20 15:23 UTC, Cosimo Cecchi
committed Details | Review
Revert "drawingarea: don't call gtk_style_context_set_background()" (2.62 KB, patch)
2015-07-20 15:23 UTC, Cosimo Cecchi
committed Details | Review
drawingarea: use same background approach as GtkLayout (2.83 KB, patch)
2015-07-20 15:23 UTC, Cosimo Cecchi
committed Details | Review

Description Felix Riemann 2015-07-19 19:36:11 UTC
Created attachment 307699 [details]
sample code showing the different behaviours

Current git master shows a change of behavior compared to 3.16 in how a GtkDrawingArea considers the background-color property.

Previously in gtk+-3.16 it would respect the property even if the application connected an own handler to the "draw" signal. That way the background could be colored independently from the actual foreground drawn by the application handler.

In current git master (due to commit 6786c9d7) it only paints the background if the application doesn't register a signal handler itself (unlikely) or allows further handlers for "draw" which would cause the GtkDrawingArea to paint over everything the application has drawn.

This affects the backwards compatibility with apps that rely on the old behaviour (like eog, for example).

I also attached a little sample program that shows the difference. In gtk+-3.16 the window will be blue, in git master it has the default background color of the theme.
Comment 1 Cosimo Cecchi 2015-07-20 15:23:30 UTC
Created attachment 307769 [details] [review]
Revert "drawingarea: checks parent's draw() before call it"

This reverts commit b3166b745f41a901171821ccc9f0c69b9cc35e70.
Comment 2 Cosimo Cecchi 2015-07-20 15:23:35 UTC
Created attachment 307770 [details] [review]
Revert "drawingarea: don't call gtk_style_context_set_background()"

This reverts commit 6786c9d724ad57ea30e169d2afcb4a314b2e56bb.
Comment 3 Cosimo Cecchi 2015-07-20 15:23:40 UTC
Created attachment 307771 [details] [review]
drawingarea: use same background approach as GtkLayout

Call gtk_style_context_set_background() every time the style is updated
and add a comment as to why we still need to do it here.
Comment 4 Cosimo Cecchi 2015-07-20 15:24:37 UTC
I tested these patches with the sample code and they seem to fix the issue.
Comment 5 Matthias Clasen 2015-07-20 15:26:20 UTC
Review of attachment 307771 [details] [review]:

Looks good to me
Comment 6 Matthias Clasen 2015-07-20 15:26:37 UTC
Review of attachment 307770 [details] [review]:

ok
Comment 7 Matthias Clasen 2015-07-20 15:26:50 UTC
Review of attachment 307769 [details] [review]:

ok
Comment 8 Cosimo Cecchi 2015-07-20 15:43:28 UTC
Attachment 307769 [details] pushed as 11ce41d - Revert "drawingarea: checks parent's draw() before call it"
Attachment 307770 [details] pushed as 90d237c - Revert "drawingarea: don't call gtk_style_context_set_background()"
Attachment 307771 [details] pushed as 62af1cb - drawingarea: use same background approach as GtkLayout
Comment 9 Felix Riemann 2015-07-20 17:51:42 UTC
Fixes the background issue for eog as well. Thanks! :)
Comment 10 Debarshi Ray 2017-05-25 19:32:06 UTC
Updated the bug status while passing by.
Comment 11 Debarshi Ray 2017-05-25 19:32:45 UTC
(In reply to Debarshi Ray from comment #10)
> Updated the bug status while passing by.

Sorry, I meant the status of the patches and not the bug.