Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!hplabs!hpfcdc!hpfclp!diamant
From: diamant@hpfclp.SDE.HP.COM (John Diamant)
Newsgroups: comp.windows.x
Subject: Re: Consortium standard version of ICCCM now available
Message-ID: <9740095@hpfclp.SDE.HP.COM>
Date: 30 Jul 89 06:02:37 GMT
References: <8907241226.AA17245@expire.lcs.mit.edu>
Organization: HP SESD, Fort Collins, CO
Lines: 48

I have a couple questions about this version of the ICCCM and the
Xlib changes in particular.

First of all, the ICCCM seems to describe a mechanism for changing
window states that requires the application to know what state it is
in prior to requesting a state change.  Many applications don't keep
track of their existing state is, and may find it inconvenient 
to maintain that information.  In looking at the
requirements in the ICCCM, it looks as though it should be possible
to combine the requirements into operations that don't care about
the existing state.  In particular:

To normalize: set WM_HINTS.initial_state to NormalState, and map the
              window
To iconize:   send the WM_CHANGE_STATE ClientMessage
To withdraw:  unmap the window and follow it with a synthetic UnmapNotify
              event

It may be necessary on iconizing to also set the WM_HINTS.initial_state
to IconicState and map the window in the iconize case -- I'm not sure,
and if it is, I'm not sure if it should be done before or after the
WM_CHANGE_STATE message.

In any case, will this work (regardless of the current state of the
window)?

This indeed seems to be exactly what XIconifyWindow and XWithdrawWindow
do (excluding the WM_HINTS and map I mention for iconize below the
initial description).  Does this mean that XIconifyWindow will work
whether the window is currently in NormalState or WithdrawnState?
If not, why not?  It would seem that these functions would be most
useful if they didn't care what the current state of the window was.

Why is there no XNormalizeWindow?  It would seem for
completeness, it would be appropriate to provide this function as well.

Finally, I noticed that the changes to the XSizeHints structure still
refer to the type "int" even though it is not the same size on each
machine.  I assume all these things called int are really supposed to
be INT32 or something.  Is that true?

Thanks,


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