Path: utzoo!utgpu!watmath!att!ucbvax!hplabs!hpfcdc!hpfclp!diamant
From: diamant@hpfclp.SDE.HP.COM (John Diamant)
Newsgroups: comp.windows.x
Subject: Re: Re: Consortium standard version of ICCCM now available
Message-ID: <9740098@hpfclp.SDE.HP.COM>
Date: 5 Aug 89 00:48:28 GMT
References: <8907241226.AA17245@expire.lcs.mit.edu>
Organization: HP SESD, Fort Collins, CO
Lines: 47

> Nope.  The ICCCM requires you to track what state you are in (as a caveat, a
> fair amount of care was taken to make sure that this wasn't too tough to do),
> and Xlib reflects that.

That's unfortunate.  It doesn't sound that easy to me.  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) or have the
application maintain a state variable for each window.  Is there an
easier way?

In any case, I still haven't heard whether my algorithm would work.  Again,
what I'm proposing is to always do the following based on the desired
state (ignoring the current state):

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

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

to withdrawn: unmap the window and send a synthetic UnmapNotify event.

It seems to me as though this will work without requiring the current
state.

> 	Why is there no XNormalizeWindow?
> 
> It was considered, but since we went to a lot of work to make a plain
> XMapWindow be the trigger, we decided not to add another function which 
> simply called XMapWindow.

Well, you do have to set the WM_HINTS first, but I was thinking more along
the lines of a level of procedural abstraction (regardless of the ICCCM
requirements, there would be simple functions to do state changes).

> Not exactly.  The XSizeHints structure is a C language construct, not a 
> network format.  The routines that manipulate the property copy the data
> into the appropriate packets (actually array of longs which XChangeProperty
> converts into CARD32's).  The real requirement is that the fields be large
> enough to hold the appropriate type of value.

Thanks for the explanation,


John Diamant
Software Engineering Systems Division
Hewlett-Packard Co.		Internet: diamant@hpfclp.sde.hp.com
Fort Collins, CO		    UUCP: {hplabs,hpfcla}!hpfclp!diamant