rws@EXPO.LCS.MIT.EDU (07/24/89)
The Inter-Client Communication Conventions Manual (ICCCM) has been adopted by the MIT X Consortium as a standard. The final document, and the final Xlib interface changes in support of the ICCCM, are available from expo.lcs.mit.edu (18.30.0.212) via anonymous ftp and the xstuff mail daemon. There is one technical change in the final ICCCM from the second Public Review version: a selection owner using INCR transfer should no longer replace targets in a MULTIPLE property with the atom INCR. There is one technical change in the Xlib interface from the Public Review version: XSetWMProperties has class hints as an additional argument. Code to implement the Xlib interface changes will not be available to the public from MIT until R4. Files via anonymous ftp are in pub/ICCCM/: icccm.tbl.ms ICCCM source (use tbl and -ms) icccm.ps ICCCM in PostScript xlib.changes Xlib changes in support of ICCCM Via xstuff, send a message with a subject line and no body, or a single-line body and no subject, in either case the line looking like: send etc <item1> ... <itemN> where the <item>'s are: icccm.tbl.ms.1 ICCCM source (use tbl and -ms) split in 3 parts icccm.tbl.ms.2 icccm.tbl.ms.3 icccm.ps.1 ICCCM in PostScript split in 8 parts icccm.ps.2 icccm.ps.3 icccm.ps.4 icccm.ps.5 icccm.ps.6 icccm.ps.7 icccm.ps.8 xlib.icccm Xlib changes in support of ICCCM
diamant@hpfclp.SDE.HP.COM (John Diamant) (07/30/89)
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!diamantjim@EXPO.LCS.MIT.EDU (Jim Fulton) (08/02/89)
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? 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. 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. 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? 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. Jim Fulton MIT X Consortium
janssen@holmes (Bill Janssen) (08/03/89)
In article <8908021342.AA23331@expo.lcs.mit.edu>, jim@EXPO (Jim Fulton) writes: >...The ICCCM requires you to track what state you are in... Why? Bill -- Bill Janssen janssen.pa@xerox.com (415) 494-4763 Xerox Palo Alto Research Center 3333 Coyote Hill Road, Palo Alto, California 94304
drk@athena.mit.edu (David R Kohr) (08/03/89)
In article <2130@arisia.Xerox.COM> janssen@holmes (Bill Janssen) writes: >In article <8908021342.AA23331@expo.lcs.mit.edu>, jim@EXPO (Jim Fulton) writes: >>...The ICCCM requires you to track what state you are in... I believe that ICCM stands for "Inter-Client Communications Manual". Could someone please briefly describe what kind of information is contained in this manual? Based on the title, it seems to be a description or specification of X's protocol for client-server communications; does it also include implementation information? Thanks,
jim@EXPO.LCS.MIT.EDU (Jim Fulton) (08/03/89)
You can retreive the ICCCM from expo.lcs.mit.edu in two ways: 1. anonymous ftp from the directory /pub/ICCCM/ 2. the xstuff mail archive server: % mail xstuff@expo.lcs.mit.edu Subject: index etc ^D % mail xstuff@expo.lcs.mit.edu Subject: send etc icccm.tbl.ms.1 ^D % mail xstuff@expo.lcs.mit.edu Subject: send etc icccm.tbl.ms.2 ^D % mail xstuff@expo.lcs.mit.edu Subject: send etc icccm.tbl.ms.3 ^D PostScript versions are also available from both sources (do an ftp directory listing or get the index from xstuff).
guy@auspex.auspex.com (Guy Harris) (08/05/89)
>You can retreive the ICCCM from expo.lcs.mit.edu in two ways: > > 1. anonymous ftp from the directory /pub/ICCCM/ > 2. the xstuff mail archive server: Note that the stuff you get from the mail archive server is not wrapped inside a shell archive (I assume this is because not all people retrieving it that way will necessarily be running UNIX or some other system capable of de-archiving shell archives), so if you retrieve it that way a few places where the word "From" appears at the beginning of the line will, if the mail passes through a UNIX system's mailer, get a ">" prepended to the "From". I remember only three such in the ICCCM, so it's not painful to remove them; it's also not painful to leave them in, just mildly unattractive.
diamant@hpfclp.SDE.HP.COM (John Diamant) (08/05/89)
> 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
David.R.Kohr@mamab.FIDONET.ORG (David R Kohr) (08/06/89)
-- Fidonet: David R Kohr via 1:363/9 Internet: David.R.Kohr@mamab.FIDONET.ORG Usenet: ...!peora!rtmvax!libcmp!mamab!David.R.Kohr
jim@EXPO.LCS.MIT.EDU (Jim Fulton) (08/09/89)
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,
Jimdiamant@hpfclp.SDE.HP.COM (John Diamant) (08/11/89)
> That's unfortunate. It doesn't sound that easy to me. > > Selecting for StructureNotify on the appropriate window will give you the > appropriate events. Only if you also maintain a state variable on the current state of the window and ignore any StructureNotify events if the window has been withdrawn (otherwise, when you get an Unmap event, you'll think the window just went iconic). This isn't trivial because of the burden of managing the state variable on each toplevel window. > 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. Yuck is right. That's my whole point. This is the only way to avoid the state variable if the algorithm I described below doesn't work. Given that there might not be a window manager running and that the ICCCM only provides suggestions for the contents of WM_STATE, this isn't even sufficient. 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. It almost seems as though you guys tried to figure out the convention that would place the largest burden on application writers possible (I'm sure you didn't, but looking at the current conventions and not knowing the history of the decisions made, it sure looks that way). > or have the application maintain a state variable for each window. > > Chances are, though, it already is. Why do you claim that? I claim that it is unlikely the application is maintaining a state variable. In general, applications have no reason to know or care what state their windows are in (sometimes, the application will know whether it's windows have been withdrawn, but it will be rare for them to know whether their windows are iconic or normal). The window manager maintains the state. A window in iconic state won't do extra work because VisibilityNotify and Expose events will take care of this. In a cursory look at the Xt Intrinsics source (R2 version -- I haven't looked at R3), it does not maintain the window state (it can't really, since it doesn't know when the window was withdrawn), but does maintain the WM_HINTS structure, thus avoiding all those extra round trips you're concerned about. > 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 This, of course, is only because the ICCCM requires the WM_HINTS.initial_state to be ignored in this case. If it had paid attention to these, it would have worked just fine, and maintaining the window state would not be necessary. > (as well as an unnecessary round trip [if WM_HINTS not passed > in by the caller] and property set). Not a pretty sight. Passing in the WM_HINTS wouldn't be that unreasonable. The Xt Intriniscs keep track of the hints structure so no extra round trip would be necessary in that case. The Xlib call could even take the WM_HINTS as an optional argument (pass NULL if the hints aren't available). > to normal: set the WM_HINTS.initial_state to NormalState and map > the window. > > 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. I don't understand why you are so concerned about one or two extra round trips to the server for an infrequent operation, when the result on the application of trying to save this step is a significantly larger burden on the application writer. > 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. Fine, I agree with the philosophy. However, you're providing a function that claims to iconify windows and you're telling me that it only works if the window is not currently withdrawn. The function XIconifyWindow() would more accurately be called XIconifyNonWithdrawnWindow(). Since the operations can only be done via ICCCM or other conventions, the Xlib philosophy would dictate that these functions not be in Xlib at all. If you're going to take the step that convenience functions are OK even if they pertain to operations based on the ICCCM, then the argument for not implementing policy breaks down (after all, the lower level functions that provide the mechanism without policy are available anyway). I guess I really don't see the advantage of providing this function in its present form. John Diamant Software Engineering Systems Division Hewlett-Packard Co. Internet: diamant@hpfclp.sde.hp.com Fort Collins, CO UUCP: {hplabs,hpfcla}!hpfclp!diamant