Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!tut.cis.ohio-state.edu!ucbvax!hplabs!hp-pcd!hpcvlx!gabe
From: gabe@hpcvlx.cv.hp.com (Gabe Begeddov)
Newsgroups: comp.windows.x
Subject: Re: question about Reparenting WM's and Xt support
Message-ID: <100920113@hpcvlx.cv.hp.com>
Date: 16 Sep 89 22:42:02 GMT
References: <2375@harrier.ukc.ac.uk>
Organization: Hewlett-Packard Co., Corvallis, OR, USA
Lines: 76


   / hpcvlx:comp.windows.x / rlh2@ukc.ac.uk (Richard Hesketh) /  8:43 am  Sep 15, 1989 /
   
   I add an event handler on each widget's window to catch ConfigureNotify
   events (ie. StructureNotify with an event->type == ConfigureNotify check).
   Now this works fine for all widget instances below the toplevel
   applicationShellWidgetClass instance.  I can call XtSetValues() and
   change the size of a widget and I get a ConfigureNotify event back
   confirming the change.  However if I try to perform XtSetValues() on the
   toplevel shell I never get a ConfigureNotify back, the window does move
   however (see (*) below for a qualification of this).

Xt tries to overlay a synchrounous model for geometry management over X. Shells
support this by doing inline event processing after generating a 
configure request. The shell swallows the configureNotify that comes back (if
you're lucky :-) if for no other reason than not to confuse the shell event
handler which would assume that the configure notify was associated with an
external rather than internally generated request. The lack of handshaking 
between the shell geometry manager and it's event handler causes other problems
which will hopefully be addressed in the R4 intrinsics.
   
   I do get ConfigureNotify's for the toplevel shell if I move or resize the
   window using the window manager and the x and y positions are set to the
   correct location (ie. where the window really starts not where the title
   bar happens to be!).  This is great and means my program does not need to
   know what kind of window manager is running (if any!).  However if use these
   values and do an immediate XtSetValues() the window does not move .. fine,
   that is just right.
   (*) But lets say the shell's current position is "said"
   to be (x,y) and we move it to (x,y+1) using XtSetValues(), the window "jumps"
   to (x, y + 1 + height_of_title_bar).  Now somebody is wrong here!  The window
   manager (twm) or the Xt Intrinsics?

This is probably twm. The Motif window manager provides a setting that 
determines whether positioning requests should be interpreted as frame 
or self relative. 
   
   Plus I never receive a ConfigureNotify event for this change in position.

see above.
   
   Looking in the ICCCM (section 4.1.5) I find that the "client" must be aware
   of the problems of reparented windows; I assume this is handled by the
   Intrinsics?

To a degree in that XtTranslateCoords and Shell now conspire to return correct
coordinates for shells when reparented . It is still the case that shell's x 
and y are not guaranteed to be correct at all times. 
   
   What I would like to know is, are the Intrinsics still out of date
   when it comes to ICCCM support or do I have really have to take notice of the
   ReparentNotify event for the toplevel shell window and do some recalculation
   of positions? 
   
The R4 Xt will be ICCC compliant. This will not solve your problem.
It is a policy decision of the window manager (hopefully based on user settable
preferences) that determines how geometry requests are handled. You could 
assume that the reason you didn't get you're requested position was because of
frame relative placement being in effect but there's no guarantee.
   
   Richard Hesketh   :   rlh2@ukc.ac.uk    ..!mcvax!ukc!rlh2
   		  :   @nsfnet-relay.ac.uk:rlh2@ukc.ac.uk

Gabe Beged-Dov