rlh2@ukc.ac.uk (Richard Hesketh) (09/15/89)
I have a toolkit program which wants to track the size and position of widget instances (its an interactive user interface builder). I am having problems with ConfigureNotify events from toplevel windows under a reparenting window manager (twm). I am using the very latest version of the intrinsics (can I be more specific in public? 8-). 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). 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? Plus I never receive a ConfigureNotify event for this change in position. 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? 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? 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 and let me use these positions in any subsequent SetValue calls. ??? Richard Richard Hesketh : rlh2@ukc.ac.uk ..!mcvax!ukc!rlh2 : @nsfnet-relay.ac.uk:rlh2@ukc.ac.uk --- Computing Lab., University of Kent at Canterbury, Canterbury, Kent, CT2 7NF, United Kingdom. Tel: (0227) 764000 ext. 3682
gabe@hpcvlx.cv.hp.com (Gabe Begeddov) (09/17/89)
/ 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
swick@ATHENA.MIT.EDU (Ralph R. Swick) (09/20/89)
> 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