GNOME Bugzilla – Bug 642221
Alt-tab should not show panel-like applications
Last modified: 2011-03-15 19:37:28 UTC
I run gkrellm. In gnome 2.x, Alt-tab would never show it. Ctrl-Alt-tab does though. In gnome-shell, it it shown in both Alt-tab and Ctrl-Alt-tab. It should not be shown in Alt-tab.
Presumably it also shows up in the dash (the icons on the left side of the overview)? Does gkrellm open both a panel-like window and also some other window? Can you type "xprop" in a terminal, click on the gkrellm window, and attach the output here?
Yes it does. I'm not sure if it should show up there though. gkrellm itself it panel-like. But its configuration dialog is just normal window. I'll attach a screenshot with gkrellm on the right side and its config dialog in the middle, and xprop.
Created attachment 180828 [details] xprop output of gkrellm
Created attachment 180829 [details] gkrellm screenshot
ok, i just tried installing gkrellm, and what I see is, if the configuration window is open, then it shows up in Alt-Tab (in both gnome-shell and metacity), and selecting it there focuses the configuration window. If the configuration window is not open, then gkrellm doesn't show up in Alt-Tab, but does show up in Ctrl-Alt-Tab, and selecting it there focuses the dock window. so, I don't see any bug.
It does show up in Alt-tab for me when conf window is not opened. I try all combination of settings in General/Settings (Sticky, Always on top/bottom, Set window type to be a dock or panel, Do not include on a taskbar/pager..). All the same. This is 2.91.6. Do I need to upgrade to master? Or is it mutter?
It is an app and should be shown. Pretty sure this is notabug.
It is a floating monitor. There's nothing to interact with. It shows things and if it draws my attention, I would interact with other parts of the system, not itself. It could always be shown with Ctrl-Alt-Tab, as metacity does.
A little help please. I'm new to gnome-shell. There's a comment in shell-window-tracker.c stating that get_running_apps() returns a list of apps that has at least one window attached. There's also shell_window_tracker_is_window_interesting() which rules out DOCK type windows. I checked with looking glass and app gkrellm has a single window type DOCK. But I don't know how this running_apps list in _ShellWindowTracker is managed. Perhaps gkrellm is accidentally added to the list?
(In reply to comment #9) > Perhaps gkrellm is accidentally added to the list? Hm... actually, this might be related to bug 598737; if gkrellm initially shows its window without the DOCK type or skip_taskbar hint, and then changes it afterward, we may not properly update it. You could add some debugging printfs to shell_window_tracker_is_window_interesting() maybe? (bug 624360 also looks like a dup of this.)
Created attachment 182965 [details] [review] ShellWindowTracker: don't create ShellApps for non-interesting windows If a process does not have any "interesting" windows, then it can't be considered a running app. (Previously we were calling get_app_for_window() before ruling out non-interesting windows, which ended up calling _shell_app_new_for_window(), which would add the window to the ShellApp directly, bypassing the is_interesting check.)
(In reply to comment #11) > Created an attachment (id=182965) [details] [review] > ShellWindowTracker: don't create ShellApps for non-interesting windows This patch fixes it for me. Thank you!
Review of attachment 182965 [details] [review]: So I think this would cause us to treat say (old) empathy and rhythmbox as not-running if their status icon thingies withdraw the windows. But that's probably OK; handling that better would be a different bug.
Attachment 182965 [details] pushed as 43020b2 - ShellWindowTracker: don't create ShellApps for non-interesting windows