Since upgrading to xpra 0.15.x (both .0 and .1 have this problem) I've had trouble with windows not appearing in the task manager. (xpra 0.14.x never had this problem.)
For example, I'll start one konsole over xpra and it will appear in the task manager. Yet when I start a second konsole it appears on screen, but not in the task manager. Unfortunately I haven't been able to pin down a pattern to which windows appear in the task bar and which ones don't. (Today, the first window I created showed up in the task bar and the rest are not. I do not, however, have consistent good luck with the first window created.) The problem does not seem to be tied to a specific application. (I mostly use konsole and gvim, but I've seen the problem with other applications as well.)
As I'm playing with things and writing this note, I see that it's having more trouble than I originally thought. I have now also seen an existing task manager entry disappear as a new window is created. The task manage entry for the new window may or may not be created.
My client and server are both running Ubuntu 14.04. My client is using KDE.
Attached is the output of the bug report tool, and the client log with "-d client"
Bug Report tool output.
Client log file with -d client
window[90] before changing virtual desktops
window[90] after changing virtual desktops
In the instance I captured, I created the xpra window immediately after connecting the client. As the screen show shows, the window does not appear in the task manager at all (so it's not a case of the task manager grouping windows or anything like that.)
In email, Antoine had asked for some details from xpra -info:
doole@reorx:~$ xpra info | egrep "window-type=|class-instance=|\.title=|transient="
window[90].class-instance=('konsole', 'Konsole')
window[90].title=hotellnx105 : doole – Konsole
window[90].window-type=('NORMAL',)
While playing with my system, I discovered that if I move the window between virtual desktops, it appears in the task manager. I captured all the details from xpra -info for window[90] before and after the virtual desktop move and have attached them to the ticket.
I'll install KDE in a 14.04 VM to try to reproduce.
Another variation on this that I noticed today. I had moved my windows between desktops so they were appearing in my task manager. I disconnected the client and then reconnected. At this point the windows were no longer appearing in my task manager. (As before, moving the windows between desktops caused them to appear in the task manager again.)
Yet another variation...
I connected my client this morning and all my windows appeared in the task bar. However, when I dragged a couple windows, they disappeared from the task bar. (Again, moving the window between desktops got it back on the task bar.)
I've just tried with an up to date Ubuntu 14.04 64-bit VM running KDE 4.13.3. There does seem to be a problem - I only encountered issues once I moved away from the current workspace (or is it activity - whatever that is), but oh my is it tedious to use this thing. How am I supposed to easily switch virtual desktops in my virtualbox vm? Where is the simple click to select workspace widget thingy?
I am seeing the problem regardless of which desktop I start out in.
I use "pager" to switch between the desktops. (Any time I've set up a KDE system it's been in the menu bar by default.)
I can verify that I'm having the same issue under 0.15.3. Pinning a window to all desktops also makes it appear in the taskbar, so I simply click the pin icon in the window titlebar and then click it again to keep the window on the desktop I originally had it on - not a fun workaround, but far faster than sending it to another desktop, switching, sending it back, and switching back.
Fix attempt that likely breaks other things
This issue has been bothering me, so I decided to delve into the code and attempt a fix. The issue seems to be with client windows not getting assigned a workspace at creation. I've attached a 2-line patch that seems to fix the issue for me, though I have no idea if it breaks other things in the process. There also seems to be an issue with windows forgetting which screen they're supposed to belong to, but I don't know if that's related to this issue. If nothing else, hopefully this will help point a real Xpra dev in the right direction.
It doesn't seem that anyone has touched this since my last update. I can report that in my case (Arch Linux, KDE 4 client, KDE 5 server), the patch seems to have fixed the problem and I haven't noticed any unusual symptoms nor additional instability. I'd be interested in seeing if this patch breaks any other client setups that lack a concept of workspaces (Windows/Cygwin?, for example). If not, it's probably safe to merge into trunk and close this issue.
I've had another look and I have 2 problems:
set_workspace has side-effects: it will realize the window, and it is the only code left that has not been converted to the new "on-realize" event callback code...
I thought I would give it a quick go... and many many hours later trunk is fixed (workspace support was completely broken there) and maybe your bug report too - but the change is quite big: r10972.
@user_rl: if you can test trunk and this also fixes your task manager problem, I will consider how to apply at least parts of it to v0.15.x
Probably similar to the problems in #1025, which are fixed in trunk. Because of the size of the changes, I will probably just leave 0.15.x as it is.
I assume this is fixed in trunk, feel free to re-open if not.
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/895