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.
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)
screenshot, tray icons squashed
Replying to totaam:
Do you have a screenshot?
See attached.
What's your desktop environment?
KDE
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.
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.
Looking at the gtk.StatusIcon
implementation in GTK2, I see that we can trigger the re-docking by:
gtk_tray_icon_clear_manager_window
is called first
gtk_tray_icon_update_manager_window
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?
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)
That appears to be fixed in 0.13.5, thank you.
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/591