KDE Frameworks is at 5.28.0. Qt at 5.7.1~20161021. But it happened with previous versions of Plasma, KF, Qt as well. Since about forever – I had this even in KDE SC 4 times already – kactivitymanager / KWin / ksmserver or whatever component is responsible do to it forgets which windows belong to which activities in certain circumstances. So far I found: - Logging in and out can or rebooting can trigger this. - kwin --replace quite reliably triggers it # How to reproduce Most reliable and easy way I found so far is: - Put some windows onto specific activities. - kwin --replace # Actual results With kwin --replace usually: - All windows on all activites With logging out, logging in or reboot: - All windows on one, usually the wrong activity # Expected results KWin / ksmserver / kactivitymanagerd or whatever else is responsible to do that reliably remembers which windows are tied to which activities across restarts of the window manager or the session.
Bug 326630 - activities do not remember applications associated with it seems about this, but there has been comments it may have been fixed. Well for me this is still happening with latest stuff.
Hmmm, I intended to report this for KWin (activities integration), but accidentally continued in the wrong browser tab. Feel free to reassign as needed.
Can confirm this bug in: Plasma: 5.12.3 Apps: 17.12.3 Frameworks: 5.44.0 Qt: 5.10.1 Kernel: 4.14.27-1-MANJARO OS: Netrunner Rolling
This issue still happens with Plasma 5.14. For me this is one of the most annoying usability issues with activities. Thus I flag it as usability and CC you this time, Nate. Maybe you or someone from your team can have a look at it. Actions that often trigger it: - Switching off and on compositing using Alt-Shift-F12, … - or by starting or ending a game that pauses compositing - kwin_x11 --replace as already mentioned I sometimes switch off and on compositing in an attempt to recent graphics when Intel open source graphics driver on Sandy Bridge becomes confused and starts to display garbage in several circumstances. Or I play such a game. So I find myself often reassigning windows at least once, if not several times a day, which is a tedious process in itself, since it involved selecting the right activity from a sub menu as far as I am aware of. Expected result: kwin / kactivitymanager always remember which activity a window is assigned to.
(In reply to Martin Steigerwald from comment #4) > This issue still happens with Plasma 5.14. On KDE Frameworks 5.54. > I sometimes switch off and on compositing in an attempt to recent graphics s/recent/reset > when Intel open source graphics driver on Sandy Bridge becomes confused and > starts to display garbage in several circumstances. Or I play such a game. > So I find myself often reassigning windows at least once, if not several > times a day, which is a tedious process in itself, since it involved > selecting the right activity from a sub menu as far as I am aware of.
Hi. Any update on this bug? It is still one of the most annoying bugs for me.
KWin saves activities. My guess is that kwin gets started before kactivitymanagerd. Can you post output of xprop of any window that is on several activities before logging out and after logging in?
(In reply to Vlad Zagorodniy from comment #7) > KWin saves activities. > > My guess is that kwin gets started before kactivitymanagerd. Can you post > output of xprop of any window that is on several activities before logging > out and after logging in? Hmmm, I did not have an issue with windows on wrong activities after logging in or logging out since a long time. I just read my original report where I mentioned it. So that part is probably fixed. The remaining issue is when for some reasion kwin_x11 crashes or is restarted: 1) either by kwin_x11 --replace 2) or by disabling and enabling compositing via Alt-Shift-F12. usually to work-around Intel graphics driver or other part of the display stack bugs (pixel garbage around windows). I bet that kactivitymanagerd would still be running with the session. Yes, it still runs. I just did the steps in 2 as I had graphics bug and its still there. I could try to save xprop after login and then after the first time the issue happens.
(In reply to Martin Steigerwald from comment #8) > I could try to save xprop after login and then after the first time the > issue happens. No need for that then, though could you post output of xprop before and after running kwin_x11 --replace?
Created attachment 121153 [details] xprop of konsole window before disabling compositing after gfx glitches happened xprop of konsole window before disabling compositing after gfx glitches happened. Before disabling compositing and after enabling it again clearly shows that the activity is lost: % grep _KDE_NET_WM_ACTIVITIES *.txt xprop-1-before-disabling-compositing.txt:_KDE_NET_WM_ACTIVITIES(STRING) = "4540d766-f31f-48a7-8823-b0b3fcd9499a" xprop-2-after-enabling-compositing-again.txt:_KDE_NET_WM_ACTIVITIES(STRING) = "00000000-0000-0000-0000-000000000000"
Created attachment 121154 [details] xprop of konsole window after enabling compositing again xprop of konsole window after enabling compositing again
*** Bug 419840 has been marked as a duplicate of this bug. ***
Removing assigned status as no activity in 3 years.