gdykes@batcomputer.tn.cornell.edu (Gene Dykes) (09/21/88)
XtSetValues looks at x,y,width,height of the new widget and compares them to the values in the current widget. If different, XtSetValues calls the geometry manager of the widget's parent. But, XtSetValues passes the "current" widget to the geometry manager instead of the "new" widget. It also passes the old constraint information, not the new. I have two related problems with this: 1) How is a geometry manager supposed to make a good layout when it is given Widget and constraint values which point to outdated information? Is it the case that the geometry manager is supposed to do a layout based solely on the geometry information of the request argument? If, for instance, I wanted to do an XtQueryGeometry on the children, I have to take care to treat the calling widget differently, because it would give bogus information to the question "What is your preferred geometry?". Is there a good rationale for passing the old information instead of the new? 2) A GeometryManager may also be affected by certain constraints of a widget. If one of these constraints is changed by XtSetValues, there is no mechanism for telling XtSetValues that the geometry manager needs to be called. Admittedly, this relayout could be done when the notification is made in ConstraintSetValues, but this seems clumsy to me and this will result in the layout being done yet another time when the Geometry Manager is called because of the new widget geometry. What I would like is for XtSetValues to pass the correct (new) information to the geometry manager and to allow the ConstraintSetValues procedure to be able to return a code that means, "The Geometry Will Change", so that XtSetValues will call the geometry manager even if x,y,width,height haven't changed. -- Gene Dykes, gdykes@tcgould.tn.cornell.edu
swick@ATHENA.MIT.EDU (Ralph R. Swick) (09/21/88)
Date: 21 Sep 88 01:48:42 GMT
From: gdykes@tcgould.tn.cornell.edu (Gene Dykes)
1) How is a geometry manager supposed to make a good layout when it is given
Widget and constraint values which point to outdated information?
It can't. You are 100% correct in your analysis of this problem. See below.
2) A GeometryManager may also be affected by certain constraints of a widget.
If one of these constraints is changed by XtSetValues, there is no mechanism
for telling XtSetValues that the geometry manager needs to be called.
This is a corollary of (1). If ConstraintSetValues were able to modify the
geometry and constraints of the widget passed to the Geometry Manager,
then your problems would be over. See below.
What I would like is for XtSetValues to pass the correct (new) information to
the geometry manager
Done. The R3 Intrinsics specification changes the values passed to the
set_values method so that the real widget is in the 'new' argument.
Semantically, this is equivalent to assuming that all requested changes
will be accepted (rather than denied). When the Geometry Manager is
invoked (on the real widget) it therefore sees all the new state.
(This is one of 3 non-source-compatible changes for widgets; it will
affect widgets which had to implement gross work-arounds in their
set_values procedures.)
and to allow the ConstraintSetValues procedure to be able
to return a code that means, "The Geometry Will Change", so that XtSetValues
will call the geometry manager even if x,y,width,height haven't changed.
I'm not sure why you want this. If the widget geometry (you left out
border_width) hasn't changed, then why is there a need for a re-layout?
In R3, ConstraintSetValues can modify any parts of the (new) widget
geometry and thereby cause the Geometry Manager to be invoked.
-Ralphasente@decwrl.dec.com (Paul Asente) (09/22/88)
In article <6365@batcomputer.tn.cornell.edu> gdykes@batcomputer.tn.cornell.edu (Gene Dykes) writes: >1) How is a geometry manager supposed to make a good layout when it is given >Widget and constraint values which point to outdated information? In order to make a decision, it has to have both the old and the new values. The old values are in the widget, and the requested new ones are in the request. The geometry manager gets passed the widget with everything updated *except* the geometry fields -- these haven't really changed until the geometry manager says they can be. All constraint fields the geometry manager gets have been updated. (This is definately true in R3; I don't remember for sure if it is true in R2). >2) A GeometryManager may also be affected by certain constraints of a widget. >If one of these constraints is changed by XtSetValues, there is no mechanism >for telling XtSetValues that the geometry manager needs to be called. Yes, this is a real problem. I solved it in a constrained widget I wrote by having the constraint set_values procedure put unlikely flag values into x and y and having the geometry manager test for them. Yes, it's a hack, and it will fail if you try to move the subwidget to x,y = -6265, -6265. Having set_values and constraint set_values return a value saying to call the geometry manager would have been a good idea, but it's too late to do anything about it now. -paul asente asente@decwrl.dec.com decwrl!asente