#895 closed defect (fixed)
Windows not appearing in task manager
Reported by: | Doug Doole | Owned by: | R |
---|---|---|---|
Priority: | major | Milestone: | 0.16 |
Component: | client | Version: | 0.15.x |
Keywords: | taskbar | Cc: | gotoindvdum@… |
Description
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"
Attachments (5)
Change History (21)
Changed 7 years ago by
Attachment: | taskmanagerinfo.zip added |
---|
Changed 7 years ago by
Attachment: | WindowDetailsBefore.txt added |
---|
window[90] before changing virtual desktops
Changed 7 years ago by
Attachment: | WindowDetailsAfter.txt added |
---|
window[90] after changing virtual desktops
comment:1 Changed 7 years ago by
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',)
comment:2 Changed 7 years ago by
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.
comment:3 Changed 7 years ago by
Status: | new → assigned |
---|
I'll install KDE in a 14.04 VM to try to reproduce.
comment:4 Changed 7 years ago by
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.)
comment:5 Changed 7 years ago by
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.)
comment:6 Changed 7 years ago by
Owner: | changed from Antoine Martin to Doug Doole |
---|---|
Status: | assigned → new |
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?
comment:7 Changed 7 years ago by
Owner: | changed from Doug Doole to Antoine Martin |
---|
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.)
comment:8 Changed 7 years ago by
Component: | android → client |
---|---|
Keywords: | taskbar added |
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.
Changed 7 years ago by
Attachment: | set_workspace_on_init.patch added |
---|
Fix attempt that likely breaks other things
comment:9 Changed 7 years ago by
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.
comment:10 Changed 7 years ago by
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.
comment:11 Changed 7 years ago by
Status: | new → assigned |
---|
I've had another look and I have 2 problems:
- I don't like applying a patch without understanding why it fixes something - not setting the workspace should have no effect! (why on earth does it change what appears in the taskbar??)
- calling
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...
comment:12 Changed 7 years ago by
Cc: | gotoindvdum@… added |
---|
comment:13 Changed 7 years ago by
Owner: | changed from Antoine Martin to R |
---|---|
Status: | assigned → new |
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
comment:14 Changed 7 years ago by
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.
comment:15 Changed 7 years ago by
Resolution: | → fixed |
---|---|
Status: | new → closed |
I assume this is fixed in trunk, feel free to re-open if not.
comment:16 Changed 16 months ago by
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/895
Bug Report tool output.