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.