Path: utzoo!utgpu!watmath!att!ucbvax!tut.cis.ohio-state.edu!bloom-beacon!EXPO.LCS.MIT.EDU!jim
From: jim@EXPO.LCS.MIT.EDU (Jim Fulton)
Newsgroups: comp.windows.x
Subject: Re: Consortium standard version of ICCCM now available
Message-ID: <8908081755.AA11823@expo.lcs.mit.edu>
Date: 8 Aug 89 17:55:14 GMT
References: <9740098@hpfclp.SDE.HP.COM>
Sender: daemon@bloom-beacon.MIT.EDU
Organization: X Consortium, MIT Laboratory for Computer Science
Lines: 57


    That's unfortunate.  It doesn't sound that easy to me.

Selecting for StructureNotify on the appropriate window will give you the
appropriate events.


    Either you have to query the server each time to find out the state of the
    window (checking WM_STATE and figuring out what it means if there isn't 
    one)

Yuck! :-)  But, I'll admit that given how infrequently the client will be
requesting these operations, it isn't too much of a burden.


    or have the application maintain a state variable for each window.

Chances are, though, it already is.


    In any case, I still haven't heard whether my algorithm would work:

    to iconic:  set the WM_HINTS.initial_state to IconicState, map the window,
		and send the WM_CHANGE_STATE message with data[0] = IconicState


Written slightly more verbosely, this translates to the following steps:

     o	fetch old WM_HINTS from server (if not passed to routine)
     o	store new WM_HINTS to server
     o	map window (causes already Iconified window to become Normal)
     o	send client message

Unfortunately, this causes already iconified windows to be deiconified and
the reiconified (as well as an unnecessary round trip [if WM_HINTS not passed
in by the caller] and property set).  Not a pretty sight.


    to normal:  set the WM_HINTS.initial_state to NormalState and map
		the window.

This one would work as desired, except that it forces an extra diddling of
the WM_HINTS property (and possibly a round trip if the client isn't passing
in the WM_HINTS) that isn't necessary.  Again, given how infrequent this is,
it probably isn't too bad.  But, if it isn't necessary, it's a shame to 
waste time or memory or to complicate the interface.  It's a choice that 
some may disagree with, particularly in this case.

For better or for worse, the philosophy behind mcuh of Xlib is to provide the
common denominators that impose as few restrictions on the calling program as
possible (the old "mechanism, not policy" litany).  Higher level routines
(including abstraction of inter-client communications) are generally left to
toolkits or application libraries.


			We'll be the first to admit that Xlib isn't pretty,
			Jim