GNOME Bugzilla – Bug 317550
No task list leads to invisible windows
Last modified: 2005-11-08 23:33:33 UTC
If I don't have a task list in my panel (the libwnck thing that flashes when a window requires attention), new windows that pop up behind the window in the front become effectively invisible until I close the front window. How to reproduce: 1. Remove the task list from your panel. 2. Create an appointment in Evolution for the next minute, and add an alarm to trigger 0 minutes before the start of the appointment. 3. Switch to a maximized window. 4. Wait a minute. 5. ... nothing seems to happen. But if you hit Alt-Tab, you'll see the alarm notification window, which is behind your maximized window.
We basically assume that you have a tasklist and aren't really designing for a use-without-tasklist case. Anyway, we could raise those windows, but having windows cover up what you're working on is just as wrong as having windows steal focus when you're busy typing in another application. So, right now, the only two possibilities I see (raise the window to the top so that it interrupts the user's work, or putting the window below the maximized window) aren't very good. If you have any bright ideas on ways of notifying the user that a new window is available without sticking it in front of the focused, maximized window, we're all ears.
I guess we could flash the window list in the panel. ... But why does Evo's alarm notification window appear behind other windows? If I run "xclock" on a terminal, it appears in front. Why is the alarm window different?
Um, you just said you don't have a task list, so how can you flash it? If a user launches an application, the tend to want to use it--so by default, we focus and raise new windows. However, if they start using another application in the mean time, they probably got tired of waiting and would rather keep using that other application instead of being interrupted mid-thought and have their keystrokes stolen. So, such windows should not get focus and should not be on top. Note that unexpected dialogs (especially errors or notifications) also should not be focused/raised because the user could easily accidentally dismiss them or select a dangerous operation before they even got a chance to read what the dialog said (in fact, I have missed several error dialogs this way--I know something popped up and wanted my attention, but it went away instantly because I happened to hit enter just as it showed up).
Marking as needinfo as per the question in comment 3.
No response; closing.
Sorry for the belated reply. I think the right behavior is to pop up new windows *above* the currently focused window (so that you can see them), but not give them the input focus (so that you don't type where you didn't intend to). When you don't have a task list, at least make sure you flash the window list menu in the panel, or do *something* that will tell me that a window is lurking somewhere.
We do flash the window list in the panel when there is one. How is this a new suggestion? Also, you've repeated again that you have no task list to flash, so your suggestion isn't making much sense. Stealing top-level is just as annoying as stealing focus; perhaps we need to invent better ways to inform the user that something has happened (and indeed there are other bugs and threads about it, some even with ideas), but switching backing to having these new surprise windows take the toplevel is just a buggy cop-out IMO. I'm against it as I've stated in a few other places.
The task list is [* Window foo ][# Window bar ][$ Window baz ] The window list is the drop-down menu of all the windows, usually in the upper-right panel. It is the latter that doesn't flash. I think I would be less annoyed if the windows popped up in front, but they didn't steal my focus. At least one would notice that they appeared.
Ahah! :) Go to your panel, right click, select "Add to panel", scroll down near the bottom and notice that "Window List" is described as "Switch between open windows using buttons". The thing you are calling the window list is correctly known as the window selector (some also call it the "window menu"), and that's what was getting me so confused here. Anyway, I thought we had more than one bug for this but it looks like 305979 is it. (If you're curious, though, there's also a flash-the-titlebar bug somewhere, an idea to have demands-attention windows show up in the window list regardless of whether it's on the same workspace that I haven't filed, various tweaks and fixes in the focus/raise/demands-attention logic I haven't had time to get to due to the constraints_experiments branch and that I also haven't filed bugs about, and a huge thread on wm-spec-list some months ago on this topic but mostly concentrating on our lack of URGENT support) *** This bug has been marked as a duplicate of 305979 ***