(In reply to comment #0)
>  * Use the application icon, and overlay a status icon as an emblem, if it is
> required (eg. Skype)

We do that if there's an associated application. We can't always find it, though.

I don't understand this. The statusicon protocol lets the panel tell the app which size it needs. Are those apps simply ignoring the size, or are we not telling them the right size ?

We're telling them the right size. sealert and the GTK+ tests show the right size.

... hm, could it be a difference between this and the Qt code? Does anybody have Qt built to run tests with?

Created attachment 221973 [details]
We could be buttonizing the 16x16px

.. if we can't find an app icon or such.

(In reply to comment #4)
> Created an attachment (id=221973) [details]
> We could be buttonizing the 16x16px
> 
> .. if we can't find an app icon or such.

+1 There will always be retarded binary blobs not presenting large enough icons and stretching looks bad.

Buttonizing the icons like Jakub recommended makes sense to me. The legacy status icons not only look different, they behave differently too. Which is one reason we should be more aggressive in getting the problematic apps ported over. We may also want to group all status icons together. Currently they are interleaved with notification sources and this is pretty awkward.

Is there anything blocking the merge of attachment #221973 [details] as a first workaround?

(In reply to comment #7)
> Is there anything blocking the merge of attachment #221973 [details] as a first
> workaround?

If there's a chance of getting this into the 3.6.x series, I'd be happy to see this happen.

I'm starting to think that we need to look at this again for 3.8 though. It's become increasingly apparent to me that the presence of these icons in the tray are really confusing people, since they don't behave like the other tray items. The result is that people don't really understand how the tray is supposed to work. A good step would be to review the existing misbehaving applications and see if we can do something on the shell side to deal with them (either by removing the tray items altogether, or treating them differently somehow).

I think buttonizing is the way to go even to indicate they'll behave differently, I hope we can indicate visually when the "button" is pressed to make clear the icon was actually clicked, since the notification closes down for legacy app in that case and *then* something happen. I don't think removing legacy apps from the tray all together is a good idea.

But what about the context menus? They behave awkwardly. Buttonizing might solve the look problem but it will result in almost-visually-similar icons behaving differently.

I tried to solve it with this [0], not the best solution but it might inspire someone to come up with a fix.

[0] https://lh5.googleusercontent.com/-XQRkn9ASR-E/UHrYeJ3QaKI/AAAAAAAACxc/bnFs29d31g0/s495/image6932.png

(In reply to comment #7)
> Is there anything blocking the merge of attachment #221973 [details] as a first
> workaround?

Nobody wrote the patch.

(In reply to comment #8)
> If there's a chance of getting this into the 3.6.x series, I'd be happy to see
> this happen.

Nope. 3.6.1 was already released.

Created attachment 227247 [details]
Screenshot demonstrating problem

The Dropbox icon is correctly centred in its allocation but the Guake one is in the top-left of its allocation.

(I just upgraded to 3.6.1 from Ubuntu 12.10 repos and noticed this - @aday told me to put a comment/screenshot here).

Created attachment 228253 [details]
screenshot of a cropped icon

Today I saw Skype icon positioned in the top-left corner of the allocation.  Then I restarted gnome-shell with Alt+F2 r and the icon was positioned correctly.

For more fun, today I saw GTimeLog's icon positioned in the center of the allocation, but cropped so that only the upper-left corner of it was visible.  Quitting and restarting the application doesn't fix it.  Restarting gnome-shell fixes this too.

I wouldn't have me-tooed mathematical.coffee's report, but the strange cropping of the gtimelog icon seemed interesting.  Also the fact that the icons get drawn correctly iff they exist when gnome-shell starts up.

gnome-shell 3.6.1 from Ubuntu 12.10.

Created attachment 229360 [details]
mockup

I think the best thing to do is to create a separate area for legacy status icons. There are two reasons for this. First, as the bug report indicates, the smaller 16x16 icons look bad - providing a bounded area designed to fit this size of icon will help here. Second, legacy icons behave differently from the other tray items, and confuse how the tray is supposed to work. Delineating these other icons will make it clearer that they operate using a different logic.

Will this allow us to do something about the behavioural brokenness of legacy status icons ? The basic problem is that we can't pop up menus while the modal message tray is shown.

Status icons are usually 22px, not 16px.

Created attachment 229392 [details]
revised mockup

OK, 22x22 then.

(In reply to comment #14)
> For more fun, today I saw GTimeLog's icon positioned in the center of the
> allocation, but cropped so that only the upper-left corner of it was visible. 
> Quitting and restarting the application doesn't fix it.  Restarting gnome-shell
> fixes this too.
> 

Seeing the same thing with SparkleShare

(In reply to comment #14)
> Created an attachment (id=228253) [details]
> screenshot of a cropped icon

I can reproduce the cropped icon problem on gnome-shell from git master. gnome-shell prefers 48x48 icons in the message tray. But the icons from gtimelog/GtkStatusIcon get cropped to 24x24 (or 22x22 for Chrome). On the client side (gtimelog), I see this call from my logs:
gtk_window_compute_configure_request()
 -> gtk_window_compute_configure_request_size()
 -> gtk_widget_get_preferred_height()
and it returns 24.

This causes gdk_window_x11_move_resize() -> XResizeWindow() to be called with 24x24 although GdkWindow->{width,height} is 48x48. So the client (gtimelog) knows the correct size but still attempt to resize to 24x24.

gnome-shell intercept the resize request in GtkSocket with a SubstructureRedirectMask on the parent. When chrome sends a ConfigureRequest of 22x22, gnome-shell correctly ignores the suggested size and send a ConfigureNotify with 48x48. Does it suggest the bug is in Chrome?

Comparing the cases where it work and the cases where it does not work, I noticed that when gnome-shell receives the PropertyNotify/WM_NORMAL_HINTS before any gtk_socket_size_request, it is fine and the image is not cropped. I am not sure if it is a race somewhere.

Follows my logs from gnome-shell by instrumenting gtk:

1. starting gtimelog (icon not cropped)

GtkSocket: gtk_socket_get_preferred_width: minimum=natural=1 !(is_mapped, have_size)
GtkSocket: gtk_socket_get_preferred_width: minimum=natural=1 !(is_mapped, have_size)
GtkSocket: add SubstructureRedirectMask for window 0x3a97c60
GtkSocket: add filter func for window 0x3a97c60
GtkSocket: got a new ReparentNotify message
GtkSocket: got a new ReparentNotify message
GtkSocket: property notification: WM_NORMAL_HINTS
GtkSocket: got a ConfigureRequest message
GtkSocket: gtk_socket_size_request: called
GtkSocket: gtk_socket_size_request: PMinSize: hints=(w=24 h=24) w=24 h=24
GtkSocket: gtk_socket_get_preferred_width: minimum=natural=24 (is_mapped, have_size)
GtkSocket: gtk_socket_get_preferred_width: minimum=natural=24 (is_mapped, have_size)

2. starting chrome (icon cropped)

GtkSocket: gtk_socket_get_preferred_width: minimum=natural=1 !(is_mapped, have_size)
GtkSocket: gtk_socket_get_preferred_width: minimum=natural=1 !(is_mapped, have_size)
GtkSocket: add SubstructureRedirectMask for window 0x360f240
GtkSocket: add filter func for window 0x360f240
GtkSocket: got a new ReparentNotify message
GtkSocket: got a new ReparentNotify message
GtkSocket: gtk_socket_get_preferred_height: requesting size...
GtkSocket: gtk_socket_size_request: called
GtkSocket: gtk_socket_size_request: PMinSize: hints=(w=0 h=0) w=1 h=1
GtkSocket: gtk_socket_get_preferred_width: minimum=natural=1 (is_mapped, have_size)
GtkSocket: gtk_socket_get_preferred_width: minimum=natural=1 (is_mapped, have_size)
GtkSocket: property notification: WM_NORMAL_HINTS
GtkSocket: property notification: WM_NORMAL_HINTS
GtkSocket: got a ConfigureRequest message: value_mask=12 [CWWidth=1 CWHeight=1 CWX=0 CWY=0] [w=22 h=22 x=0 y=0] window=0xe0001d, private->plug_window=0x360f360
GtkSocket: finished to handle ConfigureRequest message
GtkSocket: gtk_socket_get_preferred_height: requesting size...
GtkSocket: gtk_socket_size_request: called
GtkSocket: gtk_socket_size_request: PMinSize: hints=(w=22 h=22) w=22 h=22
GtkSocket: gtk_socket_get_preferred_width: minimum=natural=22 (is_mapped, have_size)
    ... And then later, when the icon is actually viewed: ...
GtkSocket: gtk_socket_get_preferred_width: minimum=natural=22 (is_mapped, have_size)
GtkSocket: gtk_socket_size_allocate: sending synthetic ConfigureNotify for window 0x360f360
GtkSocket: sending ConfigureNotify for window 0x360f360 x=2788 y=1061 w=48 h=48 override_redirect=False

Hmm, so looking briefly at na-tray-manager.c in both the shell and gnome-panel, I see the gnome-panel version has code to set _NET_SYSTEM_TRAY_ICON_SIZE, but the shell version hasn't. So much for communicating the right icon size...

_NET_SYSTEM_TRAY_ICON_SIZE is fairly recent, and is a GNOME-private property designed for symbolic icon sizes. The size of the icon is supposed to be communicated by the size of the X window.

thats what you think. Are you sure GtkStatusIcon agrees, though ?

(In reply to comment #23)
> thats what you think. Are you sure GtkStatusIcon agrees, though ?

gtk/gtktrayicon-x11.c calls XGetWindowProperty(atom for _NET_SYSTEM_TRAY_ICON_SIZE) and it returns an error. When I change gtk_tray_icon_get_icon_size_property() to always set 48, the cropping still happen.
      icon->priv->icon_size = 48;
so I don't think it is related to _NET_SYSTEM_TRAY_ICON_SIZE.

Unless we have more investigation, I don't think this should be a 3.8 blocker.

sadly, too late for 3.8

So, there's still issues with putting legacy app icons elsewhere.

First of all, legacy icons *cannot work* while in the message tray. Some of them pop up menus (which it can't do) or want to activate windows (which would work fine, but look weird). Right now we have this awful hack where we exit the message tray so that they can pop up a badly coordinated menu that comes from nowhere. We can keep doing this hack, but it's quite ugly in the code as well.

Second, we try to tie notifications to the status icon if it exists. This leads to the extremely awkward situation when you have an app with a tray icon and notifications at the same time. Click on it once, see notifications, click on it again, activate the status icon. We can drop this association, but then you might have a case where you have two Dropbox icons in the status bar.

*** Bug 728693 has been marked as a duplicate of this bug. ***

As with gnome 3.12.x, a few applications behave strangely in the system tray. Rhythmbox's icon only shows if you play something, and Deluge's start as a tiny icon but if you go to 'Preferences', disable the system tray icon and enable it again the big icon shows up again.

Is there a way to manually resize/point to a bigger icon for the message tray entries like Dropbox, Skype, etc... They are very tiny now, I can hardly see if Dropbox is syncing or not. Or do we wait for a complete update/cleanup of the message tray in the future? I'm using 3.10.1 now with ubuntu 14.04.

We have a new notifications design now [1], and while we haven't finalised how status icons will be handled, I think that it's fair to say that this bug is obsolete.

[1] https://wiki.gnome.org/Design/OS/Notifications/