josh@concept.viewlogic.com (Josh Marantz) (02/28/91)
There are times when I'd like to build a widget hierarchy bottom-up.
But the basic XtCreateWidget call takes the parent as a formal
parameter, implying what widget hierarchies must be created top-down.
I have two questions for the Intrinsics experts:
1. Can NULL be specified as a parent at creation time, and re-set
once the parent has been created? There is an XtParent(). Is
there something like XtSetParent, or XtSetArg(arg, XtNparent, parent)?
2. What is the reasoning behind mandating that widget hierarchies
be created top-down? To me, Bottom-up has two advantages:
1. You could create hiearchies with a C expression that
syntactically reflected the hierarchy:
menu = create_menu (create_entry ("File", ...),
create_entry ("Edit", ...),
create_entry ("View", ...),
create_entry ("Help", ...),
...
NULL);
2. By the time the real top-level window was created, all
component widget sizes would be known, and if constraint
windows could determine their appropriate size before
the call to XCreateWindow. (I know this is handled in
Xt by the multi-phase Create-Manage-Realize strategy).
I'm curious as to why this approach was taken.
--
Joshua Marantz
Viewlogic Systems, Inc.
josh@viewlogic.com
Why not pass the time by playing a little solitaire?asente@adobe.com (Paul Asente) (02/28/91)
The reason Xt mandates top-down widget construction is resources. If you allowed parentless construction of the widget "fred" and there was a resource specification: mary.bob.thelma.fred.width: 30 you would have to recompute fred's resources (or delay computing them) when the final place in the widget tree was determined. I guarantee that this two-phase resource resolution would make the current multi-phase creation look simple by comparison. It also means that the advantage described, that the parent could know the geometries of all its children when being created, wouldn't really be an advantage. There could be another resource specification mary.bart.thelma.fred.width:50 and when "fred" was added to "thelma" the size of "fred" would remain unknown until "thelma" was added to "bob" or "bart". -"paul" asente asente@adobe.com ...decwrl!adobe!asente
toml@marvin.Solbourne.COM (Tom LaStrange) (02/28/91)
> The reason Xt mandates top-down widget construction is resources. If you > allowed parentless construction of the widget "fred" and there was a resource > specification: > > mary.bob.thelma.fred.width: 30 > > you would have to recompute fred's resources (or delay computing them) when > the final place in the widget tree was determined. I guarantee that this > two-phase resource resolution would make the current multi-phase creation > look simple by comparison. It also means that the advantage described, that > the parent could know the geometries of all its children when being created, > wouldn't really be an advantage. There could be another resource specification > > mary.bart.thelma.fred.width:50 > > and when "fred" was added to "thelma" the size of "fred" would remain unknown > until "thelma" was added to "bob" or "bart". > We have exactly this situation in OI because it allows dynamic reparenting of objects and does not require a specific order of creation of object hierarchies. We fetch resources on an object when it is associated with a new parent and it's top-level ancestor is parented to the root. We will also re-fetch resources on an object when it is reparented to another object hierarchy and it's new top-level ancestor is on the root. This makes reusing trees of objects very nice. Consider the following resource specifications: application*mary*background: blue application*mary*font: variable application*bart*background: red application*bart*font: 9x15 Then we associated a dialog box to mary. If the top-level ancestor is on the root, the dialog box will be blue with a variable font. If we then move the dialog box so that bart is it's new parent, the dialog box will be red and use a 9x15 font. The OI also allows the programmer to re-fetch resources at any time on an object. The question came up a few days ago where the person wanted to add some resources via XrmPutLineResource and then re-fetch resources. In OI you would simply use the object->update_resources() member function. -- Tom LaStrange toml@Solbourne.COM