Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!lll-winken!uunet!mcvax!ukc!harrier.ukc.ac.uk!rlh2
From: rlh2@ukc.ac.uk (Richard Hesketh)
Newsgroups: comp.windows.x
Subject: X Toolkit XtCWQueryOnly and ICCCM window managers
Message-ID: <733@harrier.ukc.ac.uk>
Date: 22 Apr 89 17:02:16 GMT
Reply-To: rlh2@ukc.ac.uk (Richard Hesketh)
Organization: Computing Lab, University of Kent at Canterbury, UK.
Lines: 32

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