[Adobe-source-devel] Re: asl-users: Widget Parenting Issues

[Sean P. <sp...@ad...>]

On Jan 30, 2006, at 2:26 PM, Foster T. Brereton wrote:

> On Jan 30, 2006, at 01:58p, Tom Pinkerton wrote:
>
>> Hi All,
>>
>> While digging into my Qt implementation of the widgets library,  
>> I've noticed
>> that a widget's parent appears to be set after the underlying  
>> platform
>> widget itself is created. On MacOS this is not a problem because a  
>> control
>> can be initially created without a parent. However, the existing  
>> Windows
>> implementation uses some kind of 'invisible parent' member as an  
>> initial
>> parent when a control is created. In Qt, like on Windows, a widget  
>> needs a
>> parent at creation time, so I'm wondering if I will need a similar
>> 'invisible parent' mechanism for my Qt implementation.
>
> Yes, you will need to do the same for Qt.

The rational for display_t was to begin to abstract away the notion  
of a view hierarchy from the widgets that the hierarchy contains -  
we're going for an STL container model here as opposed to an  
obtrusive "every object has it's own list of children".

The principal of minimal requirements for an interface then implies  
that a widget would not have knowledge of this container, but rather  
would be associated with the view hierarchy after construction.

Because display_t actually lives within the framework (Win32, QT,  
whatever) - our implementation is a thin interface shim (much as  
checkbox_t is a thin shim on the platform checkbox interface). The  
invisible window is a hack so that checkbox_t and display_t can  
maintain a correct interface.

>
>> Does Eve somehow rely
>> upon setting the parent after a widget is initially created?
>
> Yes -- this is due to the fact that the widgets themselves aren't  
> supposed to manage their child-parent relationships; this is  
> modeled currently by the separation of the ui_core from the display  
> code. The display's intent is to manage parent/child relationships  
> within the visual heirarchy, completely separate from the widgets  
> themselves. A widget is first created in the ui_core, then it is  
> attached to the visual hierarchy through the display code. Thus, it  
> must exist before it can be attached, requiring the invisible  
> window for platforms where widgets must be contained by a window at  
> all times.

To correct Foster, The Eve layout engine does not make such an  
assumption - Eve doesn't even deal with the construction pass at all.  
This is handled through the eve_evaluate code (which exists to make  
it easier to connect the data coming out of the eve parser with a  
widget factory and an eve layout). The design here is purely part of  
the widget library. Eve can be wired to an existing framework without  
going through the widget library - in fact the widget library started  
life as throw away code in Begin to demonstrate how to Eve up to a  
framework (the original implementation was done with the proxy  
objects direct to Mac Carbon controls). It became apparent that have  
a thin "widget library" would make adoption of Adam and Eve simpler  
so we've been working to rework the widget library in a way which is  
intended to be framework independent.

>
>> Is the sole
>> purpose of the display_t object to provide a way to set the  
>> widget's parent
>> hierarchy?
>
> Yes. Sean had other justifications for the display code, but I  
> can't remember them currently.
>
>> Will the parent hierarchy ever change for a given Eve layout
>> after the initial layout is created?
>
> No -- the description of the layout specifies the hierarchy, and it  
> is parsed only when the view is first created. Ralph Thomas has  
> done some work with populating parents dynamically with children as  
> an optimization (e.g., only populating a scrollable list of image  
> thumbnails with those thumbs that are currently in the view  
> clipping rect) but it's not a part of ASL currently. Note this is a  
> different behavior from hiding and showing widgets, however (which  
> is something we do support).

The engine does support adding nodes to the graph post initial layout  
- although we don't make use if it in the current code (as Foster  
points out, Ralph is making use of it). It doesn't currently support  
removing nodes (the optional panel is handled by filtering nodes  
within the layout, not removing them). The ability to remove nodes  
may be added in the future if there is strong demand - but it is  
generally a risky prospect. If you remove a node you would invalidate  
any iterators to that node or it's children and widgets currently  
communicate with the layout by hanging onto their position. Robust  
support for remove would require something like slots/signals to  
notify connected items that they were being disconnected. I haven't  
found a use case for this yet.

>
> Keep the questions coming!
>
> Blessings,
> Foster
>
>
> --
> Foster T. Brereton              <}}}><              Romans 3:21-26
> A d o b e   S o f t w a r e   T e c h n o l o g y   L a b
> "The fact is that the author of STL does not know how to write min,  
> the author of C++ is not quite sure, and the standards committee is  
> at a loss." -- Alexander Stepanov
>
>