GNOME Bugzilla – Bug 647082
app menu disappears when a dialog window is focused
Last modified: 2011-04-12 21:57:18 UTC
Dialog windows tend to be marked skip_taskbar. Thus, ShellWindowTracker considers them un-interesting, and so when one gets focused, it doesn't know what app it belongs to, and so the app menu disappears. So we need to either (a) keep track of un-interesting windows too, but just not include them in shell_app_get_windows(), or (b) not keep track of them, but belatedly figure out what app they belong to in shell-window-tracker.c:on_focus_window_changed(). Although this is not really related to bug 646184, it may make sense to fix them together...
*** Bug 647473 has been marked as a duplicate of this bug. ***
Note this is a regression introduced from the patch in bug 642221. (In reply to comment #0) > > So we need to either (a) keep track of un-interesting windows too, but just not > include them in shell_app_get_windows() What happened in bug 642221 is that the app wasn't tracked, and we created an app from it backend by the window, which ended up in the "running apps" list and thus alt-tab. I think it makes sense to exclude them from shell_app_get_windows(); it would mirror what we're currently doing in workspace.js. But this seems like it's only slightly kicking the can down the road; the current alt-tab code would then go back to showing the app, and bug 642221 would reappear. If I click on gkrellm and it takes X focus, I'd still expect to see it in the application menu, no? So we need to track it. This implies we should change the alt-tab dialog to simply not list apps that have no interesting windows.
Hmm, if we change alt-tab though, this raises the question of what we do about the dash.
(In reply to comment #2) > If I click on gkrellm and it takes X focus, I'd still expect to see it in the > application menu, no? Well, mutter won't focus it when you click on it, because it's _NET_WM_WINDOW_TYPE_DOCK. But you can Ctrl+Alt+Tab to it... In that case though, I don't feel that either showing it in the app menu or not showing it in the app menu is any more obviously correct than the other. (In reply to comment #3) > Hmm, if we change alt-tab though, this raises the question of what we do about > the dash. If shell_app_activate() would be able to do something useful with the app, then it should be in both Alt+Tab and the dock. If it wouldn't be able to, then it shouldn't be in either.
(In reply to comment #4) > (In reply to comment #2) > > If I click on gkrellm and it takes X focus, I'd still expect to see it in the > > application menu, no? > > Well, mutter won't focus it when you click on it, I'm able to focus it here (Fedora 15, gkrellm-2.3.5-4.fc15, mutter-3.0.0-1.fc15). > because it's > _NET_WM_WINDOW_TYPE_DOCK. Oh...hm, it's actually _TYPE_NORMAL here, but also undecorated. Now I'm confused, because the output in bug 642221 clearly shows _DOCK. But the reporter didn't say which version he was testing with. But wait, I see, there are configuration options for all of this =) Wow. [ ] Set window type to be a dock or panel [ ] Use window manager decorations [ ] Do not include on a taskbar [ ] Do not include on a pager > If shell_app_activate() would be able to do something useful with the app, then > it should be in both Alt+Tab and the dock. If it wouldn't be able to, then it > shouldn't be in either. Makes sense. So...let me check the option to make it be a dock. Now I can't move it, annoying; and wow workspaces are broken with just this. Ok, setting this stuff aside =) Ok, I think I have a simple patch. Incoming.
Created attachment 185835 [details] [review] ShellWindowTracker: Follow transients for focus app As a side effect of (see bug 642221), we no longer put docks or transient windows into the hash table mapping windows to apps. The "focused application" code relied on at least transients being in there. Fix this by calling the public API to map a window to an app, which will at least follow transients. Whether we also want further matching here (e.g. with window grouping) is another issue, but that can happen as a different bug.
Comment on attachment 185835 [details] [review] ShellWindowTracker: Follow transients for focus app fixes the bug, doesn't seem to introduce any new ones.
Attachment 185835 [details] pushed as db6caac - ShellWindowTracker: Follow transients for focus app