GNOME Bugzilla – Bug 722690
Conky starts to appear in taskbar or app switcher with gs 3.10.3
Last modified: 2014-02-04 21:50:52 UTC
Hi all, I'm on a archlinux 64bit machine.. after recent update of gnome-shell package (from v3.10.2 to v3.10.3), Conky and may be other similar apps like some dock apps) starts to appear in taskbar or application swtcher I didn't change the conky config and Conky is always the same I'm quit sure that this never happens with all previous gnome3 shell versions, I guess this is not the expected behaviour for those kind of apps Downgrading to gnome-shel 3.10.2 solve the issue (at least for me) Best regards Andrea ps: I've attached some evidence if could be useful
Created attachment 266863 [details] conky appears in dash e app swicther
... starts to appear in taskbar AND in the application swtcher... :-) Andrea
This doesn't seem to be a conky limitation as it happens also with the nautilus file manager with no opened windows if you use nautilus to serve your desktop. If you move to conky or nautilus (File) window using ALT+<key above tab> the whole shell crashes. Confirmed in Arch Linux x86_64 gnome-shell 3.10.3-1 nautilus 3.10.1-1 conky 1.9.0-2
Created attachment 266878 [details] Task switcher Only the Firefox window is opened Conky and File are undecorated windows in the background
I can confirm this beahviour. I have the exact same problems with conky and cairo-dock. Running Gnome-Shell/Mutter 3.10.3-1 on Arch Linux x86_64.
I 've got the same problem with conky and gdesklets. My system is Arch Linux x86_64 with gnome-shell 3.10.3-1 Downgrading to gnome-shell 3.10.2-4 works fine.
(In reply to comment #6) > I 've got the same problem with conky and gdesklets. Please, don't add any more "me too" comments. This is almost certainly fallout from https://git.gnome.org/browse/gnome-shell/commit?id=e19faff101fe65c4. There's a patch in bug 722434 (the third one) that should be usable as workaround until we come up with a proper fix ...
Created attachment 266904 [details] [review] shell-app: Don't create ShellApps for uninteresting windows
(In reply to comment #0) > ps: I've attached some evidence if could be useful +1 to this. It's getting very, very annoying. Happens in "Dash To Dock" for both conky windows I have setup.
Review of attachment 266904 [details] [review]: I haven't checked whether the patch fixes the problem with conky, but if it does it's somewhat accidental. Basically an app should be considered running if it has at least one interesting window, but according to the code an app is running if it has any tracked windows - that was obviously fine while we were only tracking interesting windows, but that's no longer the case. Now, whether an application has at least one interesting window has nothing to do whether it is window backed or not - for instance nautilus' DESKTOP window is not, but we still don't want to nautilus to show up as running if that's the only window.
Created attachment 266986 [details] [review] shell-app: Base running state on "interesting" windows An app should be considered running if it has at least one "interesting" window, however the code considers an app running if it has at least one tracked window. This was fine while we were only tracking interesting windows, but since commit d21aa0d85fc325 this is no longer the case. So keep track of the number of interesting windows as well and use that to determine the running state.
*** Bug 722774 has been marked as a duplicate of this bug. ***
Review of attachment 266986 [details] [review]: Yep. This looks good.
Attachment 266986 [details] pushed as b62c157 - shell-app: Base running state on "interesting" windows
*** Bug 722837 has been marked as a duplicate of this bug. ***
*** Bug 722510 has been marked as a duplicate of this bug. ***
*** Bug 722961 has been marked as a duplicate of this bug. ***
Created attachment 268099 [details] [review] This patch prevents shell app from unreferencing a state for an app which has still uninteresting windows open. Florian's patch might work for Conky, but it solved only parts of the "Nautilus icon" bug (#722510). In fact the patch makes it even worse, since Gnome crashed every time after I closed a Nautilus window and clicked on the desktop afterwards. This is caused by shell_app_state_transition, which unreferences the running state of the app even if there are still some uninteresting windows open. My patch changes this, so that the running state is only unreferenced if there are absolutely no windows (interesting or not) open.
Created attachment 268101 [details] [review] v1 leaks memory if the last closed window of an app is uninteresting
That's already fixed in bug 722840.
Created attachment 268103 [details] [review] ui-panel: Filter uninteresting windows As Florian is suggesting in https://git.gnome.org/browse/gnome-shell/commit?id=e19faff101fe65c4 uninteresting windows should be filtered when it's actually needed. This patch filters "uninteresting windows" where needed in ui-panel. This patch in conjunction with my previous patch fixes the "Nautilus icon" bug for me.
(In reply to comment #21) > Created an attachment (id=268103) [details] [review] > ui-panel: Filter uninteresting windows See bug 722928.