Path: utzoo!attcan!uunet!tut.cis.ohio-state.edu!husc6!bloom-beacon!EXPO.LCS.MIT.EDU!rws
From: rws@EXPO.LCS.MIT.EDU
Newsgroups: comp.windows.x
Subject: Re: iconifying windows, etc.
Message-ID: <8908141156.AA00736@expire.lcs.mit.edu>
Date: 14 Aug 89 11:56:03 GMT
References: <9740099@hpfclp.SDE.HP.COM>
Sender: daemon@bloom-beacon.MIT.EDU
Organization: The Internet
Lines: 21


    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.