Xpra: Ticket #591: tray icons stacked in upper-left corner after "xpra upgrade"

When I upgraded server-side Xpra from 0.12.7 to 0.13.3 and re-attached to session using client 0.13.3 -- tray icons of running applications appeared stacked on top of each other in upper-left corner.

Sat, 07 Jun 2014 12:25:04 GMT - Antoine Martin: owner changed

Do you have a screenshot? What's your desktop environment? What applications are using the tray? Is this a regression? (there were no noticeable changes in the tray code since 0.12.x)

Sun, 08 Jun 2014 01:13:57 GMT - onlyjob: attachment set

screenshot, tray icons squashed

Sun, 08 Jun 2014 01:28:53 GMT - onlyjob:

Replying to totaam:

Do you have a screenshot?

See attached.

What's your desktop environment?


What applications are using the tray?

All of them. On screenshot there are icons from KDE wallet manager, ktorrent and QuiteRSS (bottom to top).

Is this a regression? (there were no noticeable changes in the tray code since 0.12.x)

Although I didn't notice this problem on 0.12 I'm not sure if it is a regression. This is somehow related to upgrade: if I terminate application and start it again its tray icon appears in tray properly.

Sun, 08 Jun 2014 17:28:54 GMT - onlyjob: summary changed

Tue, 10 Jun 2014 15:48:15 GMT - Antoine Martin:

Confirmed: what happens is that the tray windows look like regular OR windows, and the tray icon windows do not request docking into the new tray..

That's because the systemtray spec does not define any mechanism for taking over existing tray icons. I wonder how/if this works with regular DEs, and if so, how.

If not, we will have to hack something to let the new tray know which OR windows it should dock automatically.

Thu, 12 Jun 2014 05:36:00 GMT - Antoine Martin: owner, status changed

Looking at the gtk.StatusIcon implementation in GTK2, I see that we can trigger the re-docking by:

The first one should be called by gtk_tray_icon_manager_window_destroyed when it receives a DestroyNotify on the manager_window (which is the XGetSelectionOwner(_NET_SYSTEM_TRAY_Sn)). That should already happen?

The second one should be called when it receives a ClientMessage of type MANAGER with data _NET_SYSTEM_TRAY_Sn, which is what we do after we have claimed the selection. So this should already work?

Thu, 12 Jun 2014 11:19:57 GMT - Antoine Martin: owner, status changed

Found the solution by looking at the code in trayion (FreeDesktop? trayicon area for Ion3): fixed in r6755.

Does that work for you? (will backport)

Sat, 14 Jun 2014 03:53:58 GMT - onlyjob:

That appears to be fixed in 0.13.5, thank you.

Sat, 14 Jun 2014 05:25:53 GMT - Antoine Martin: status changed; resolution set

Sat, 23 Jan 2021 05:00:16 GMT - migration script:

this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/591