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 698901 - nm-applet systray icon size issues
nm-applet systray icon size issues
Status: RESOLVED FIXED
Product: NetworkManager
Classification: Platform
Component: nm-applet
unspecified
Other Linux
: Normal normal
: ---
Assigned To: NetworkManager maintainer(s)
NetworkManager maintainer(s)
: 702087 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2013-04-25 21:58 UTC by Sebastian Pipping
Modified: 2013-06-29 17:32 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Drawing error with XFWM/xfce4-panel 4.10.0 (Gentoo Linux) (5.74 KB, image/png)
2013-04-25 21:59 UTC, Sebastian Pipping
  Details
Drawing error with Awesome 3.5.1 (Arch Linux) (1.24 KB, image/jpeg)
2013-04-25 22:01 UTC, Sebastian Pipping
  Details
Approach (a) against nm-applet 0.9.6.4 (1.26 KB, patch)
2013-04-25 22:17 UTC, Sebastian Pipping
none Details | Review
Approach (a) against nm-applet 0.9.6.4 (v2) (1.49 KB, patch)
2013-05-23 22:34 UTC, Sebastian Pipping
committed Details | Review

Description Sebastian Pipping 2013-04-25 21:58:10 UTC
Symptoms
========
When asked for an icon of width x, nm-applet may return an icon
larger(!) than requested.  That is causing drawing errors with
certain window managers, e.g. with Awesome and XFWM (of XFCE 4).
Example screenshots are attached.
Also, the issue is documented to be known in the wiki of Awesome
(http://awesome.naquadah.org/wiki/Nm-applet#known_issue).


Causes
======
nm-applet is using GTK function "gtk_icon_theme_load_icon" to load
the systray icon using the call

  gtk_icon_theme_load_icon (applet->icon_theme, name, applet->icon_size, 0, &error);

By default, gtk_icon_theme_load_icon sticks to the sizes of the
bitmap it finds on disk, in my case these files:

  # ls -1 /usr/share/icons/hicolor/*/apps/nm-device-wired.*
  /usr/share/icons/hicolor/16x16/apps/nm-device-wired.png
  /usr/share/icons/hicolor/22x22/apps/nm-device-wired.png
  /usr/share/icons/hicolor/32x32/apps/nm-device-wired.png
  /usr/share/icons/hicolor/scalable/apps/nm-device-wired.svg

Now when when asked for an icon of width 17, the 22x22 icon is served (unscaled).  That's too big and the cause of the drawing errors.


Solution
========
I can think of two approaches:

 a) Exact icon size, reduced image quality for off-grid sizes.
      When requesting an icon of width x, an icon of exact width
      x should be returned, flag GTK_ICON_LOOKUP_FORCE_SIZE can do.

 b) Exact size or smaller (rather than bigger)
      The next smallest bitmap size can be obtained from
      a call to GTK function "gtk-icon-theme-get-icon-sizes".
      For size request smaller than the smallest bitmap
      (e.g. width of 14) flag GTK_ICON_LOOKUP_FORCE_SIZE
      could be used for a scaled version.

In either case, the line

  applet->icon_size = MAX (16, size);

should be changed to

  applet->icon_size = MAX (1, size);


A patch for approach (a) is attached.
I should mention, that it does not solve the case on Awesome yet,
since Awesome seems to be requesting sizes larger than the actual
space; a bit weird, needs more debugging, help welcome!

I can make a patch for approach (b) for you, if you prefer that one.

Looking forward to your feedback.

Best,



Sebastian
Comment 1 Sebastian Pipping 2013-04-25 21:59:28 UTC
Created attachment 242474 [details]
Drawing error with XFWM/xfce4-panel 4.10.0 (Gentoo Linux)
Comment 2 Sebastian Pipping 2013-04-25 22:01:00 UTC
Created attachment 242475 [details]
Drawing error with Awesome 3.5.1 (Arch Linux)
Comment 3 Sebastian Pipping 2013-04-25 22:17:53 UTC
Created attachment 242476 [details] [review]
Approach (a) against nm-applet 0.9.6.4
Comment 4 Sebastian Pipping 2013-05-02 11:42:26 UTC
Any comments?

PS: This issue is bugging basically everyone I know to use network-manager.
Comment 5 Andreas Hechenberger 2013-05-13 13:32:56 UTC
Hey folks,
i have the same problem. I use awesome and the menubar is very small. Sometimes the icon fits the right size and randomly it doesn't. 
If the icon is to big, i can not see the lock symbol for the openvpn service.
I use the nm-applet (Version: 0.9.4.1-5)

Is this fixed in the new versions?
Thx for developing :)
Comment 6 Dan Winship 2013-05-13 15:11:40 UTC
(In reply to comment #0)
> Also, the issue is documented to be known in the wiki of Awesome

"Wiki of Awesome" sounds like the name of some magical artifact from Dungeons and Dragons... :)

>  a) Exact icon size, reduced image quality for off-grid sizes.
>       When requesting an icon of width x, an icon of exact width
>       x should be returned, flag GTK_ICON_LOOKUP_FORCE_SIZE can do.

Yes, I think that's the right fix.

> In either case, the line
> 
>   applet->icon_size = MAX (16, size);
> 
> should be changed to
> 
>   applet->icon_size = MAX (1, size);

Why?

In particular, this means that if status_icon_size_changed_cb() initially gets called with "0", then it will set icon_size to 1 instead, and then pointlessly do the math to scale the 16x16 icons down to 1x1...
Comment 7 Sebastian Pipping 2013-05-13 20:37:50 UTC
> > In either case, the line
> > 
> >   applet->icon_size = MAX (16, size);
> > 
> > should be changed to
> > 
> >   applet->icon_size = MAX (1, size);
> 
> Why?
> 
> In particular, this means that if status_icon_size_changed_cb() initially gets
> called with "0", then it will set icon_size to 1 instead, and then pointlessly
> do the math to scale the 16x16 icons down to 1x1...

Speaking for 0.9.6.4 at least, that code (function status_icon_size_changed_cb) is not just called initially, but again and again.  When I resize the panel in XFCE, this can be observed:

  # NMA_SIZE_DEBUG=yesplease ./src/nm-applet
  [..]
  ** Message: status_icon_size_changed_cb(): status icon size now 22
  ** Message: status_icon_size_changed_cb(): status icon size now 14

So even icons of size 14 can be requested.  With "MAX (16, size)" in place, we get an icon too big again, so that would not be a complete fix for me.
Comment 8 Dan Winship 2013-05-22 15:16:02 UTC
ok, in that case, I'd suggest:

  applet->icon_size = size ? size : 16;

Can you try that out and if it works, submit an updated patch?
Comment 9 Sebastian Pipping 2013-05-23 22:34:54 UTC
Created attachment 245201 [details] [review]
Approach (a) against nm-applet 0.9.6.4 (v2)

(In reply to comment #8)
> ok, in that case, I'd suggest:
> 
>   applet->icon_size = size ? size : 16;
> 
> Can you try that out and if it works, submit an updated patch?

Here you go.  Seems to work well for me.
Comment 10 Dan Winship 2013-05-24 13:33:32 UTC
fixed in master and 0.9.8 branch. Thanks.
Comment 11 Dan Winship 2013-06-12 12:59:19 UTC
*** Bug 702087 has been marked as a duplicate of this bug. ***
Comment 12 Sebastian Pipping 2013-06-29 17:32:23 UTC
(In reply to comment #1)
> Created an attachment (id=242474) [details]
> Drawing error with XFWM

For the record, despite running a patched version of nm-applet for a while now, the drawing issues as seen in the shot above appeared again.  So that seems to be yet another issue.

Also, some users of Awesome still seem to have issues with mis-sized nm-applet icons, potentially due misbehavior on the side of Awesome.  I hope to find more about that myself, but I appreciate any debugging help from users of Awesome.