After updating to KDE 4.10, I am experiencing the following problem. I open an application, lets say Dolphin...when I minimize this application(or maybe after some time the application is being idle) it's trace from task manager dissapears and the only way to re-display it is to open System Activity(Ctrl+Esc), right-click on the process and select "Show Application Window". Of course the trace is still dissapeared after that. The only way to make it appear again is to close and re-open it, but when I minimized it I am getting in the same loop Reproducible: Always Steps to Reproduce: 1. Open some applications 2. Minimize them or click the show Desktop widget 3. Assert that no open application has traces on Task Manager Expected Results: I expect, that the traces remains on Task Manager, so that I can click on them and re-display the application
Created attachment 77089 [details] Screenshot of the problem. As you can see, Chrome is open but not in the task manager on the bottom of the screen
Just curious...does anybody else has this kind of problem or it is just me?
Just FYI, I don't have the problem using 4.10.0 in Archlinux. However, I did notice similar problem a few days ago in Gentoo using KDE built from git master . Fortunately, it go away after massive live reemerging yesterday. So to sum it up, I can't reproduce the problem.
I have the problem here, on Gentoo, kde 4.10. But not always. Just after starting the session, there is no problem. But after some time, I start having apps disappearing from the taskbar. If those windows get notifications, they suddenly appear (flashing). Then stay on the taskbar until I switch desktop. Then they disappear again. The issue is only with the taskbar : when switching windows (alt-tab) or using the windows presentation or desktop grid, the apps are shown.
Hello guys, @ Guillaume, similar status here. Yesterday I realized that all my application where on task manager and I thought that after an update of dependencies maybe it has fixed itself. But I was wrong because after some seconds almost all of them dissapeared. Our difference is that I dont use multiple windows.
It seems that since this patch [1] fixing some case of crash is applied to qt-core-4.8.4, the issue "seems" to have vanished for me. Perhaps some issue hidden under the hood was solved with this ? [1] http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/x11-libs/qt-core/files/fix-call-to-QMetaObject-metaCall-from-updateProperty.patch?view=markup
(In reply to comment #7) > It seems that since this patch [1] fixing some case of crash is applied to > qt-core-4.8.4, the issue "seems" to have vanished for me. > Perhaps some issue hidden under the hood was solved with this ? Sorry, posted too fast.... After some hours without triggering this issue, I reproduced it again just now. I only did that : - firefox was present in the taskbar - quit and start again firefox - now firefox is open on the desktop, but not anymore shown in the taskbar. The way it looks random is strange. And it's impossible to find any error log. Nothing in .xsession-errors or anywhere else...
Just one mode thing : this seems to be a kwin issue : "kquitapp plasma-desktop ; plasma-desktop" => changes nothing "kquitapp kwin ; kwin" => brings all the apps back in the taskbar
Hi Guillaume, I moved the sections after your previous comment.
(In reply to comment #9) > Just one mode thing : this seems to be a kwin issue : > > "kquitapp plasma-desktop ; plasma-desktop" => changes nothing > "kquitapp kwin ; kwin" => brings all the apps back in the taskbar If you exit the WM it will re-map all windows (by netwm requirements) and more like in a side effect bring them back to the taskbar. (the windows are re-unmapped by the following kwin start, the mapping information is temporarily stored on the window) I have strong doubts that this is even remotely related to the WM, esp. since afaik entirely new taskbar code was in the pipeline. Please replace kwin with eg. openbox and see whether the issue is still present (or only still present with kwin)
Hi Thomas, I didnt notice any problems today and it seems that Openbox causes no problems. Let me check it a few more days.
I stay with the impression that kwin is involved in some way: when starting my kde session, this bug is quite quickly triggered. This is a matter of minutes to hours. Usually, the first windows that disappear from the taskbar are firefox and psi (windows that often change their titles ?). When this happens, I restart kwin that restore all the windows in the taskbar as stated before. But moreover, after having restarted kwin, the bug seems not to be triggered anymore. I'm running a "restarted" kwin since some days now, and this bug has not shown up since the kwin restart... So, should there be some issue when registering windows at session startup or something like this ? (disclaimer, I absolutely do not know how all this stuff work internally)
Hello, I am pretty sure too, that Kwin is the problem. I am using openbox instead of kwin the last few days and it is pretty damn stable.
Do the disappearing clients start automatically with the session?
Not for me
Do this: a) fetch the window id of a windows that you suspect to "disappear" (on minimization, is it?!) more or less likely: xwininfo | grep -i "Window id:" The interesting part is the hex number, like eg. 0x1a0001e b) Once the window is minimized, do NOT attempt to fetch it back (for the moment), have konsole open and run: xwininfo -id 0x1a0001e > vanished_win.info xprop -id 0x1a0001e > vanished_win.props xprop -root | grep '_NET_CLIENT_LIST_STACKING(WINDOW)' > exported.stack and attach the output files here. (of course replace 0x1a0001e by the actual window id you obtained in a)
Found it !! This seems activity related. Windows not showing up in the taskbar ALL share one common point in xprop output: _KDE_NET_WM_ACTIVITIES(STRING) = "00000000-0000-0000-0000-000000000000" I have only one activity configured. But if I uncheck the checkbox "display only tasks from the current activity" (In french it's "Afficher uniquement les tâches de l'activité actuelle") in the taskbar configuration, all the windows not showing up in the taskbar (but that should) suddenly appear. After restarting kwin, those windows now have a not null _KDE_NET_WM_ACTIVITIES property: - if app was started with the session : _KDE_NET_WM_ACTIVITIES(STRING) = "ALL" or - if app was started manually after that : _KDE_NET_WM_ACTIVITIES(STRING) = "29cd4846-78ac-401c-9318-206c06742a95"
Yes, suspected sth. like this. This is a result of the async activity attribute loading which initially responds an invalid activity. This has been resolved https://git.reviewboard.kde.org/r/107855/ but the change is in git master (4.11) only... we may require some sort of partial backport / otherwayround fix for 4.10
*** Bug 315968 has been marked as a duplicate of this bug. ***
Created attachment 77691 [details] patch attempt Can please anyone check whether the patch solves the issue?
I just rebuilt kwin with the patch applied and restarted my kde session. For now, I can say that all windows that were previously reporting _KDE_NET_WM_ACTIVITIES(STRING) = "00000000-0000-0000-0000-000000000000" with xprop now reports _KDE_NET_WM_ACTIVITIES(STRING) = "ALL". I currently do not reproduce the taskbar issue, but it may be too early.
After 24h of using my kde session, it seems the issue is fixed by this patch. Thanks !!
Git commit 569f79c60f8fd2b3e655433c2c53f840b4c103e9 by Thomas Lübking. Committed on 02/03/2013 at 22:27. Pushed by luebking into branch 'KDE/4.10'. Map NULL_UUID activity to ALL activities REVIEW: 109274 FIXED-IN: 4.10.2 M +10 -0 kwin/client.cpp http://commits.kde.org/kde-workspace/569f79c60f8fd2b3e655433c2c53f840b4c103e9
Git commit be5d237036f786dce5e5f6923b056794fe64a10d by Thomas Lübking. Committed on 02/03/2013 at 22:27. Pushed by luebking into branch 'master'. Map NULL_UUID activity to ALL activities REVIEW: 109274 FIXED-IN: 4.10.2 M +4 -0 kwin/client.cpp http://commits.kde.org/kde-workspace/be5d237036f786dce5e5f6923b056794fe64a10d