rlh2@ukc.ac.uk (Richard Hesketh) (04/23/89)
I have a layout widget with a complete geometry manager and have found an anomaly in the way XtCWQueryOnly works for Geometry Requests that are chained up to the window manager level. The definition of the XtCWQueryOnly flag as given in Section 6.2 of the Intrinsics manual is: "XtCWQueryOnly indicates that the corresponding geometry request is only a query as to what would happen if this request were made and that no widgets should actually be changed." Upon reading the current draft of the ICCCM (Section 4.1.5), I can find no equivalent operation for the window manager. You can only request the window manager for an actual size change, which may or may not be granted or may be partially granted (I assume these to be analogous to the XtGeometryDone, XtGeometryNo and XtGeometryAlmost return values). The current implementation of the Shell Widget Class completely ignores the XtCWQueryOnly flag however, is this due to the Shell Widget being non ICCCM conformant or not completely updated to R3? It would be easy to implement a "fly-back" scheme in the Shell widget where an asynchronously received result for a geometry change would cause another request to be made to undo the change if XtCWQueryOnly flag was set. Is this going to be done in the Shell Widget or, better still, can a change be made in the ICCCM to accommodate a geometry request query between a client and a window manager? The current situation of watching your top level windows bounce about is something less than pleasing. Richard
dshr@SUN.COM (David Rosenthal) (04/24/89)
Background for my reply: A client in general has no control over the geometry, stack order & location of its top-level window. It can request the window manager to provide a particular geometry and location, but this may not be granted. Clients must accept whatever geometry, stack order and location they are given. The geometry, stack order and location of a top-level window may change arbitrarily at any time, through user interaction with the window manager or by its autonomous operation. > It would be easy to implement a "fly-back" scheme in the Shell widget > where an asynchronously received result for a geometry change would cause > another request to be made to undo the change if XtCWQueryOnly flag was set. > Is this going to be done in the Shell Widget or, better still, can a change > be made in the ICCCM to accommodate a geometry request query between a client > and a window manager? > There would be no real point in making a change to the ICCCM: - It would be slow. - It would be subject to race conditions. - It would simply reinforce the illusion that a client is in charge of its top-level geometry. The real problem is that the toolkit doesn't seem to make Shell widgets special enough. Unlike other widgets, they are subject to arbitrary size change at any time through an agency that will not brook questions or disagreement. Clients which place too much importance on the geometry of their top-level window are just badly designed. A client should work correctly with any top-level window geometry. The toolkit should make this easy. David.
ben@hpcvlx.HP.COM (Benjamin Ellsworth) (04/26/89)
> The real problem is that the toolkit doesn't seem to make Shell > widgets special enough. Unlike other widgets, they are subject to > arbitrary size change at any time through an agency that will not > brook questions or disagreement. Hmmmm??? All widgets must provide a "resize" procedure which must be able to handle an arbitrary size change without *any* questions or disagreement. The acutal "agency" may be somewhat different, but the requirement is identical. > ... A client should work correctly with any top-level window > geometry. ... I think that you have missed the point. The desire is not for client control of geometry. The desire is for the client to be able to initiate and negotiate a change in geometry (much like a widget can request and negotiate with it's parent). Why shouldn't a client be able to negotiate a geometry with the window manager? In fact, a possible model would be to consider the window manager to be the "parent widget" of all the clients on the screen. Geometry management (in terms of protocol) between clients is then identical to geometry management within clients. > David. ----------------------------------------------------------------------- Benjamin Ellsworth | ben@cv.hp.com | INTERNET Hewlett-Packard Company | {backbone}!hplabs!hp-pcd!ben | UUCP 1000 N.E. Circle | (USA) (503) 750-4980 | FAX Corvallis, OR 97330 | (USA) (503) 757-2000 | VOICE ----------------------------------------------------------------------- All relevant disclaimers apply. -----------------------------------------------------------------------