Path: utzoo!attcan!uunet!cs.utexas.edu!tut.cis.ohio-state.edu!ucbvax!bloom-beacon!SUN.COM!dshr
From: dshr@SUN.COM (David Rosenthal)
Newsgroups: comp.windows.x
Subject: Re: X Toolkit XtCWQueryOnly and ICCCM window managers
Message-ID: <8904241839.AA08092@devnull.sun.com>
Date: 24 Apr 89 16:25:20 GMT
Sender: daemon@bloom-beacon.MIT.EDU
Organization: The Internet
Lines: 35

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.