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

[Tom P. <tpi...@ad...>]

This makes sense. The beauty of it is to re-implement the display module
required changing only a single line of code. Very nice.

Thanks,

Tom


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