adobe-source-devel

[Adobe-source-devel] Widget Parenting Issues

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

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. Does Eve somehow rely
upon setting the parent after a widget is initially created? Is the sole
purpose of the display_t object to provide a way to set the widget's parent
hierarchy? Will the parent hierarchy ever change for a given Eve layout
after the initial layout is created?

Thanks,

Tom

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

[Foster T. B. <fbr...@ad...>]

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.

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

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

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

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

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

[Ralph T. <ra...@gm...>]

On 1/30/06, Sean Parent <sp...@ad...> wrote:
> 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.

The only reason I've been able to get away with removing and sorting
widgets so far is that:

 1. I always remove the widget and all of it's children (I create an
assemblage for each child widget to ensure this).
 2. I don't have any optional_panel children, so none of the widgets
use the iterator that they have into Eve.

I don't understand why you would need a signal/slot system to support
(re)move, you could just have another function in the signal_suite for
"your eve iterator has changed". There might be problems if you tried
to change anything in Eve when you received that signal though!

Ralph

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

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

[Tony V. E. <to...@ad...>]

If it helps with implementation issues, you can easily reparent a Window 
to another parent using SetParent() (at least within the same process). 
  I suspect all controls could start with the same parent - an invisible 
window hiding somewhere, and then be reparented 'when the time is right'.


Tony Van Eerd
Adobe Waterloo
-via Thunderbird-

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. Does Eve somehow rely
> upon setting the parent after a widget is initially created? Is the sole
> purpose of the display_t object to provide a way to set the widget's parent
> hierarchy? Will the parent hierarchy ever change for a given Eve layout
> after the initial layout is created?
> 
> Thanks,
> 
> Tom
> 
> 

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

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

And it was also brought to my attention that you can indeed re-parent a Qt
widget that is initially created with a NULL parent - very good to know. The
only question then is whether there's any significant overhead involved if
this means each such widget is first created as a platform window and then
changed to a child view when re-parented. I'll guess I'll cross that
bridge...

Thanks,

Tom


> If it helps with implementation issues, you can easily reparent a Window
> to another parent using SetParent() (at least within the same process).
>   I suspect all controls could start with the same parent - an invisible
> window hiding somewhere, and then be reparented 'when the time is right'.
> 
> 
> Tony Van Eerd
> Adobe Waterloo
> -via Thunderbird-
> 
> 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. Does Eve somehow rely
>> upon setting the parent after a widget is initially created? Is the sole
>> purpose of the display_t object to provide a way to set the widget's parent
>> hierarchy? Will the parent hierarchy ever change for a given Eve layout
>> after the initial layout is created?
>> 
>> Thanks,
>> 
>> Tom