GNOME Bugzilla – Bug 122122
disable shading on modal dialogs
Last modified: 2004-12-22 21:47:04 UTC
We think that _NET_WM_ACTION_SHADE should be disabled for modal dialog. Modal dialog can be made shaded by just double-clicking on its title bar(by default) which sometimes happens unintentionally and user often looses shaded window among other windows on the screen. Loosing dialog can lead to a confusion for user since if it is modal it blocks the interaction with the rest of the application and user might not understand what to do in this situation. Another effect of shading window is that it becomes Iconic which is not what people expect from modal dialogs as well. In fact, we disable MINIMIZE using MWM hints(and frame menu paints Minimize as disabled), but it seems Metacity disregards this information when it shades the window.
Modal dialogs are allowed shading to provide a quick view of anything they might obscure. This is what the HIG intended. They should probably unshade if the user tries to focus the transient parent. Maybe they already do; I haven't checked. Iconic only means that the client window is unmapped. It doesn't correspond 1-to-1 to any of iconified, minimized, shaded, hidden, etc. (Of course, direct Minimize should not be allowed because that leaves no visible representation of the dialog, because they shouldn't be in the window list. Only minimizing the parent should minimize modal dialogs.)
If one wants to observe something that is obscured he can just move the window. I doubt users use shading often, but I have been observing the confusion on the user's faces when they accidently shaded the window and that gives me the reason to think the shading idea is broken. The problem with iconification is that we should interpret WM_STATE(Iconic) as the dialog has been iconified. And we must notify developer of this change - send appropriate events and call callbacks. And this contradicts with what developer expects - he disabled iconification but receives the events. As a minimal solution we would like to see disabling of SHADE action when MINIMIZE action is disabled. Another problem is cross-WM compatibility. If you leave the window in the SHADED state AND WM_STATE as IconicState, another WM with different desktop notion about IconicState(which interprets IconicState as iconified) will show the window as iconified, not as shaded. Only after it becomes deiconified it will be SHADED. I think that instead of moving the window into IconicState you should just unmap the window.
There's a long thread in wm-spec-list archives about IconicState. It does _not_ mean minimized; the ICCCM requires IconicState whenever the window is unmapped, basically. If you want to make semantic guarantees in Swing about when you can get minimization events, you will need to filter some of the IconicState change events out; the code in libwnck may help show how to do this. Note, shading isn't the only way you can get in IconicState - metacity also puts windows on other workspaces in IconicState. And certainly the app can't turn that off. ;-) Are you sure your arguments apply only to modal dialogs? Some of them seem like they are general points about any window, i.e. just arguments that shading is a confusing concept (perhaps especially to people from a Windows/Mac background). Note that metacity can be configured so double-click maximizes instead, which probably keeps users from encountering the issue most of the time. Not that this is an excuse, just a workaround. ;-)
Gregory makes an important point, which is that when you focus a modal-shadowed window we need to be doing a raise/focus/unminimize/unshade on its dialogs; this is something that's been an important outstanding fix for quite a while.
we also need to figure out what to do when an application ends up with its modal dialog on a different workspace. This can happen sometimes to me with browsing windows open on multiple workspaces, and, for example, a connection on another workspace times out, popping up an application-modal dialog. This results in galeon seeming to freeze completely.
> There's a long thread in wm-spec-list archives about IconicState. It does _not_ mean minimized; - We are aware that some other WMs misuse this state for their own purposes. We don't agree that they should do so because of cross-WM compatibility reason. >Are you sure your arguments apply only to modal dialogs? Well, while for other windows it just represents unexpected, probably erroneous, behavior, for modal dialogs it can be critical since modal dialogs block input and while the user is confused and unable to find the way to restore the dialog the only possible exit from the situation he sees is to kill the application. We want to avoid that.
Havoc: Shading shouldn't confuse Mac users. For a long time, Mac had only Close and Zoom buttons and double-clicking the titlebar shaded the window. A button for Collapse (shade) was added in MacOS 8 to visually indicate the affordance. Versions 7-9 did not have either minimize or iconify; there was only only Hide and Collapse. Hidden windows could be unhidden from the "Application Menu" which was as an icon on the top-right corner of the screen. As far as I've been able to tell, Apple never had iconify or minimize in any OS until MacOS X, and they may be credited with inventing shading.
I think we should consider bug #123162 (remove shading from default UI), but I don't think it makes sense to special-case modal dialogs. I'm not sure bug #123162 is right anyhow. The ICCCM clearly states that you _must_ place a window in IconicState when unmapping it, so this is why shading must put a window in IconicState. I don't believe that is a bug.
Hmm, you write is as there is a explicit statement in ICCCM for WM behavior when it unmaps the window however I don't see such a statement. Could you probably cite the paragraph on which you've made this conclusions? What I see: 4.1.4 "Only the client can effect a transition into or out of the Withdrawn state. Once a client's window has left the Withdrawn state, the window will be mapped if it is in the Normal state and the window will be unmapped if it is in the Iconic state. Reparenting window managers must unmap the client's window when it is in the Iconic state, even if an ancestor window being unmapped renders the client's window unviewable. Conversely, if a reparenting window manager renders the client's window unviewable by unmapping an ancestor, the client's window is by definition in the Iconic state and must also be unmapped." It says only about necessary mapping and unmapping, and unmapping if IconicState. It doesn't say "unmapped then Iconic". Another reference: 4.2.5 "A top-level window that is not Withdrawn will be in the Normal state if it is mapped and in the Iconic state if it is unmapped. This will be true even if the window has been reparented; the window manager will unmap the window as well as its parent when switching to the Iconic state." Again, it says "unmapped when Iconic", not in the opposite direction. Anyway, another remaining issue is that we don't want some of our windows to be shaded. I agree that for some cases it is useful to have shaded windows, but in some cases it might be dangerous(for example for application or system modal dialogs). Therefore we ask to extend the protocol to include the means for specifying such a flavor for windows. Should I probably file a feature request against EWMH?
the paragraphs that you just quoted say explictly that a window that is unmapped but not Withdrawn must be in the Iconic state.
There has been massive discussion of the IconicState issue. See the citation of ICCCM in this message: http://mail.gnome.org/archives/wm-spec-list/2001-December/msg00020.html That thread is only one of several that ultimately lead to STATE_HIDDEN, STATE_MINIMIZED in EWMH though. Anyway this issue has been heavily discussed. Lubos and I want to deprecate the MWM hints and introduce new hints to replace them. This would be an opportunity to allow controlling the shaded state. However, I think you'll find that people want to deprecate control over the specifics of the window's functions in favor of the semantic hints (DIALOG, MODAL, UTILITY, etc.). So it's likely that the MWM hint replacement will allow only the "undecorated" flag and there will be no undeprecated way to control which buttons a window has. You're approaching this the wrong way; the whole purpose of the X window manager architecture is for the app to _not_ control these things. Apps are _required_ to be able to handle the WM unmapping, resizing, or whatever their windows at any time. That is what the specs specify.
The way to proceed I would say is to get things moving on wm-spec-list to resolve the MWM hints issue. We need to create a new set of well-defined hints to replace MWM hints.