Path: utzoo!censor!geac!jtsv16!uunet!bloom-beacon!ATHENA.MIT.EDU!swick
From: swick@ATHENA.MIT.EDU (Ralph R. Swick)
Newsgroups: comp.windows.x
Subject: Re: question about Reparenting WM's and Xt support
Message-ID: <8909192354.AA09107@LYRE.MIT.EDU>
Date: 19 Sep 89 23:54:14 GMT
References: <2375@harrier.ukc.ac.uk>
Organization: DEC/MIT Project Athena
Lines: 59

> I add an event handler on each widget's window to catch ConfigureNotify
> events ... 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).

Shells are ugly, there's no two ways about it.  The purpose of
the ShellWidget is to hide as many gory details of ICCCM compliance
from the application as possible.  In your case, it may be doing
too good a job :-).  The ConfigureNotify from the XtSetValues
call is being swallowed internally by the Shell widget, behind
the back of the rest of Xt event dispatching.  I'll look at this
and see if I think things can be made transparent for you, but
it's not currently high priority.

> 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!).

Well, the ICCCM says you'll probably get multiple ConfigureNotify's
at some points; some will have "correct" coordinates and some won't.

> 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!

yep; if (x,y) came from a ConfigureNotify then you'll have to be
a little more careful in your application.  If (x,y) came from
XtGetValues (or the equivalent), then I'm more interested.  If
(x,y) came from XtTranslateCoords, then I suspect you don't have
up-to-date sources for Xt.

> 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?

yes, mostly.  XtTranslateCoords will always give you a correct value.
It is possible that XtGetValues on a shell widget may not currently
guarantee a correct value, but I'm willing to consider that to be
a bug.

> do I have really have to take notice of the
> ReparentNotify event for the toplevel shell window and do some recalculation
> of positions?

yes, if you're going to be looking at raw events.

> My feeling is that because I am receiving the event through
> a toolkit registered event handler the toolkit should hide the fact that
> the window has been reparented and give me the correct positions

If you mean that XtTranslateCoords should give you root-relative
positions or that XtGetValues should give you "logical" positions
(i.e. positions for a client window as defined by the ICCCM, taking
window_gravity into account, etc.), then I'll agree.  If you mean
that somehow Xt should mung the contents of events before dispatching
them, I'll strongly disagree.

-Ralph