Path: utzoo!attcan!uunet!tut.cis.ohio-state.edu!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: <9740099@hpfclp.SDE.HP.COM> Date: 11 Aug 89 04:15:30 GMT References: <8907241226.AA17245@expire.lcs.mit.edu> Organization: HP SESD, Fort Collins, CO Lines: 106 > 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