GNOME Bugzilla – Bug 673749
Error Message When Creating Tray Icon
Last modified: 2012-05-17 19:18:44 UTC
With GTK-3.4.0, using of gtk_status_icon_new_from_pixbuf() gives this error message: GdkPixbuf-CRITICAL **: gdk_pixbuf_scale_simple: assertion `dest_width > 0' failed However, the tray icon is created correctly.
Looks like tray icons aren't rendered in a tray area with less than 18 pixels with GTK+ 3.4. Looks like only "generic" icons are affected. Please see the bug report[1] posted to the Debian BTS for more details. It can easily be reproduced with the trayer command, as specified in [1]. This same problem seems to be related to crashes in notification daemon, as reported in the BTS[2]. In that specific report, anomie suggests that a specific commit[3] may have caused the issues. anomie said: "The problem seems to be that GtkStatusIcon defaults to a size of 4 somewhere, and then rounds this down to 0, and so tries to make a zero-sized icon. If the critical warning doesn't terminate the program, GtkStatusIcon will later on get a larger size and create an appropriately-sized icon. As far as I can tell, older versions of GTK didn't do this because they used a minimum size of GTK_ICON_SIZE_MENU rather than 0 for GtkStatusIcons." Any help troubleshooting this would be greatly appreciated. [1]: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=670890 [2]: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=669883 [3]: http://git.gnome.org/browse/gtk+/commit/gtk/gtkstatusicon.c?id=2e01dc1b7a134a6482f39ae7b3b6c840442c93db Thanks in advance,
Created attachment 213900 [details] [review] Proposed patch
Hi, I've a patch that fixes this issue. The problem is in round_pixel_size in gtkstatusicon.c. Credit goes to anomie (from the Debian BTS report) for the detailed troubleshooting. The current algorithm is broken since for any tray area that is smaller than the size of a GTK_ICON_SIZE_MENU icon, the icon size will be set to 0. This was a regression apparently introduced in: http://git.gnome.org/browse/gtk+/commit/gtk/gtkstatusicon.c?id=2e01dc1b7a134a6482f39ae7b3b6c840442c93db The patch should apply cleanly to the gtk-3-4 branch. I didn't format it with git format-patch because I'm having unrelated autoreconf trouble. To apply it: $ cd /path/to/git-repo-root $ patch -p0 <~/gtkstatusicon.c.patch If needed I can submit it in git format-patch format. Regards,
Created attachment 213975 [details] [review] Alternative approach I'm attaching a patch that implements an alternative approach. It calculates the difference between the icon size in the theme to the requested size considering the sign. So if you request for size 62 and you test sizes 32 and 64, you'll get 64 as the best match instead of 32. I can think of a third approach. We could consider the best match to be the icon size that is closest but also either equal to or greater than the requested size. This way, we would only have to scale down (unless the requested size is larger than the maximum icon size). I'd really appreciate some feedback from someone that is used to this code base. This seems to be an important issue, I believe the fix could make it into 3.4.4.
Cosimo, I think this is fallout from your IconHelper conversion. Can you have a look ?
Hi Fernando, I pushed a slightly modified version of your second patch to git master (using abs() instead of computing dw and dh separately), and tested this with the trayer reproducer from the Debian bug report - it works fine with the patch. Thanks, closing as FIXED.
Thank you! Shouldn't this be committed to the 3.4 branch too? Regards,
(In reply to comment #7) > Thank you! > > Shouldn't this be committed to the 3.4 branch too? Yeah, I now pushed it there too.