rws@EXPO.LCS.MIT.EDU (08/14/89)
So, it appears there is really no reliable way
to determine the window's current state if you don't maintain a state
variable internally in the program.
The vast majority of applications should not be attempting to alter their state
from normalized to iconic or vice versa. If they are, something's wrong. To
do so is to duplicate WM functionality, and potentially conflict with the desires
of the user and with the UI of the WM. Transitions to and from the withdrawn
state are of course expected, and shouldn't be difficult, since the withdrawn
state is totally under control of the application. If some additional burden
(like keeping a state variable) falls on applications trying to do something
"out of the ordinary", I think that's acceptable.
A window in iconic state won't do extra work because VisibilityNotify and
Expose events will take care of this.
This is incorrect, unfortunately. Visibility events don't cover the case of
going iconic; there is no VisibilityNotViewable event, the server only sends
an UnmapNotify event. If the application is going to track this event, then
it's most of the way to knowing the window state.diamant@hpfclp.SDE.HP.COM (John Diamant) (08/21/89)
From: rws@EXPO.LCS.MIT.EDU > So, it appears there is really no reliable way > to determine the window's current state if you don't maintain a state > variable internally in the program. > > The vast majority of applications should not be attempting to alter their > state from normalized to iconic or vice versa. If they are, something's > wrong. To do so is to duplicate WM functionality, and potentially conflict > with the desires of the user and with the UI of the WM. You may be correct that this is infrequent. However, there are legitimate reasons for an application to request state changes. For instance, an application which provides a programmatic (scripting) interface to it's full functionality would have good reason to do this. You might say that this is really functionality of the window manager and thus should be a window manager feature, but this would make the application's programmatic access non-portable. Relying on non-ICCCM features of a window manager is discouraged by the ICCCM (not disallowed), and it is for good reason that this is so. As a result, if the application wants to function properly with any ICCCM window manager, the programmatic iconization interface must be in the application (since this access path to the window manager is defined by the ICCCM). Another example (which is really a human factors issue which could be argued for days without ever coming to a resolution) is that an application may want to have a way of bringing attention to itself when it has completed certain operations. An application that did this without allowing the user to turn this behavior on or off would be less than ideal, but if the user requests the functionality, then it is not in conflict with the user's desires, and the WM has every right to grant the request only in a way that is compatible with it's user interface policy. I don't wish to debate whether this is a good interface or not. It is an issue for human factors to decide with appropraiate concrete evidence (user testing). However, it is an issue of policy, not mechanism, and is clearly outside of the scope of either ICCCM or Xlib/X Protocol standardization. I mention it only to point out that the issue is not as clear cut as it may appear. > If some additional burden > (like keeping a state variable) falls on applications trying to do something > "out of the ordinary", I think that's acceptable. If you are correct about the frequency of applications trying to do this, then I would agree that it is not a big deal. However, I don't actually know what this frequency is and I have pointed out above that there are legitimate reasons for doing state changes within the program. In my personal experience, the frequency has been higher than you suggest, but I don't have a large enough sample to judge. > A window in iconic state won't do extra work because VisibilityNotify and > Expose events will take care of this. > > This is incorrect, unfortunately. Visibility events don't cover the case of > going iconic; there is no VisibilityNotViewable event, the server only sends > an UnmapNotify event. If the application is going to track this event, then > it's most of the way to knowing the window state. Oops. You're right, of course. For applications that don't do continuous update type things, it probably isn't that big a deal. It simply means the application is no more efficient when iconic than normal. It is no slower either, so in many cases, this will be acceptable and the application will not bother with this optimization. In any case, I realize that the ICCCM 1.0 version is now frozen and would like to see the issue revisited at the next revision opportunity for the ICCCM (R5?). John Diamant Software Engineering Systems Division Hewlett-Packard Co. Internet: diamant@hpfclp.sde.hp.com Fort Collins, CO UUCP: {hplabs,hpfcla}!hpfclp!diamant