GNOME Bugzilla – Bug 90590
Bug or misfeature? Metacity not showing "transient" windows on taskbar
Last modified: 2004-12-22 21:47:04 UTC
I'm not sure if this was intentional or not, but Metacity isn't showing "transient" windows on the taskbar or the task menu in the GNOME menu panel. While this is fine and dandy for truly transient windows like file selection dialogs, it makes keeping track of things like Mozilla's download dialogs a real pain. I have to shade Mozilla windows just to double-check whether the downloads are done. Ugh. If this is a bug, well, then it's a bug. If this is intentional, though, it definitely qualifies as a misfeature.
The problem is that some transients definitely should not be shown, such as input methods. If you look at the closed bugs you'll find one with a lot of discussion about this change. (The change is actually in libwnck not metacity, though. Metacity doesn't do the taskbar.) So, some transients it might be nice to show, some it might be nice not to show. A preference would make users choose which set of breakages they want, which is IMO quite wrong. We should instead have stable/predictable behavior so app programmers can get it right. The "don't show any transients" approach is one, the other is to show transients by default, but let apps set the skip_taskbar hint on particular transients. But most current input methods etc. don't set this hint. Anyway any choice here will break something, which in my mind means we should do what we think is the right long-term state, keep that stable, and let apps adapt to it.
What Metacity--or libwnck, whatever--did before had worked just fine. If by "input methods", you mean things like file selection dialogs, then I can't see any great loss in having them show up on the taskbar. Transient windows that are *really* transient, such as file selection dialogs or error message dialogs, can't clutter up the taskbar for long, anyway, since they aren't around all that long.
Input methods are used to input text in Chinese and Japanese and other languages, they aren't dialogs at all.
*** Bug 90696 has been marked as a duplicate of this bug. ***
*** Bug 91118 has been marked as a duplicate of this bug. ***
The original bug with discussion is bug #83483. Everyone should read that discussion before adding comments here. (Also, no <aol> comments please ;-) add substantive info... It seems the complaint everyone has with current behavior is with Mozilla download dialogs. The basic point here is, either input methods or mozilla need to change. (Or we need to hardcode a workaround for one in metacity.) The argument on original bug #83483, made by Calum, is that mozilla download dialogs should be changed. I think I agree with Calum on this, we should fix mozilla vs. fixing input methods. Conveniently, mozilla developers already agree on this and have already filed a bug report: http://bugzilla.mozilla.org/show_bug.cgi?id=65508 So, if the only argument here is about mozilla download dialogs, I think we should call this a mozilla bug. If there are examples of genuine dialogs that should be in the window list, then that would be new information we should consider. I think most things that should be in the window list probably are not really dialogs, though, much like the moz download dialogs.
Comment from a GnomeICU developer.. Should we change windows we wamt to show in the taskbar (message windows) to use gtkwindow instead of gtkdialog, is there a way to make gtkdialogs appear in the tasklist? And for as long as moz isnt fixed, it would be nice to be able to revert to the previous behavior.
For the GnomeICU windows, it doesn't depend only on this; dialogs will have other behaviors, such as being centered by default, staying on top of their transient parent, etc. The right thing to do is that if the window "is" a dialog you mark it as such, and then you let the desktop figure out how to treat it. The point about the mozilla download dialogs is that they are not really dialogs, i.e. should be treated as main windows. This is a combination of wanting them in the tasklist, not wanting them to stay on top of a transient parent, etc. > And for as long as moz isnt fixed, it would be nice to be able to > revert to the previous behavior. You could just as logically say "as long as metacity isn't changed, it would be nice to fix mozilla's behavior," as far as I can see. A preference is long-term clutter that has to be supported, prefs shouldn't be introduced with the expectation that they'll vanish in a month.
Okay, I read #83483 and realised the cost of popping up an entry into tasklist every keystrokes. But I still think this is a compromise, because I have popped up a Sessions preferences dialog and testing whether a program is SM aware, then found that I have to pop up anotherone because I thought I have closed the previous dialog. Basically, the experience is simply of a surprise! (unpredictable consistency)
There's a better fix in the works, that omits windows transient for an application window from tasklist, instead of any window marked as a dialog. This means for example control panels will show up in the tasklist.
Fix committed where only true transients skip the tasklist, rather than "any dialog"