There's some similarity in this to the ToolBar. There, conceptually, you have a
set of tools (a set of buttons, items, whatever) that live as content in the
toolbar. When the set of tools change some magic is done so that the tools
animate in a nice transition. Specifically the old set and the new set need to
be visible at the same time.
The solution there was to specifically not use parent-child relationship as the
public API for specifying tools for the toolbar but instead expose a property
"tools" that you use. That way we have a formal way that allows us to implement
magic behind the scenes (whether it's one container per all children or one per
child).
For the Menu this approach would look something like:
Menu {
items: MenuLayout {
MenuItem {}
MenuItem {}
MenuItem {}
}
}
Peppe
From: "Jokela Pekka.E (Nokia-MS-Qt/Tampere)"
<[email protected]<mailto:[email protected]>>
Date: Fri, 18 Mar 2011 08:00:39 +0200
To: Petrus Lundqvist
<[email protected]<mailto:[email protected]>>,
"[email protected]<mailto:[email protected]>"
<[email protected]<mailto:[email protected]>>
Subject: RE: [Qt-qml] internal re-parenting of child items
Thanks Peppe, I do agree.
Let me twist the problem around:
Instead of exposing a single middle-man for all the children, let’s have one
middle-man per children. In this case, the Menu would do the layouting nicely
(without any Column), but would like to add some effects to the items:
The same
Menu {
MenuItem { …}
MenuItem { …}
MenuItem { opacity: 0.8; …}
}
Internally, the Menu would like to fade the outer items with lowering their
opacity. The Menu would not like to override the user-defined values in the
MenuItem API, but introduce a middle-man which would be used for the effects.
So, the application QML would be internally translated into item hierarchy as
Menu {
MenuItemContainer { MenuItem {.. } }
MenuItemContainer { MenuItem { .. } }
MenuItemContainer { MenuItem { opacity: 0.8;.. } }
}
Same question applies:
What would be the recommended pattern?
#1 never change the default property
#2 never mix’n’match static and dynamic allocation of child items
#3 expose middle-man as ‘container’ element which can be used in dynamic
allocation
#4 provide always functions to add/remove dynamic stuff
#5 re-parent dynamically added children to the middle-man inside the
onChildrenChanged
#6 let the user do the nasty bit – they can make it work if they really want to
#7 something else?
-P
From: Lundqvist Petrus (Nokia-MS/Helsinki)
Sent: 17.03.2011 10:19
To: Jokela Pekka.E (Nokia-MS-Qt/Tampere);
[email protected]<mailto:[email protected]>
Subject: Re: [Qt-qml] internal re-parenting of child items
I would say #7:
Try to reduce the amount of magic to an absolute minimum. If you have MenuItems
seemingly in a Menu but really they end up in a container then you run into
troubles like this. IMHO it's better to make the user type a little bit more
but have it be very clear what happens. I don't know of any project that was
late because developers couldn't type fast enough. :)
So my personal recommendation would be to not have a magical column but rather
an explicit MenuLayout. Make the QML hierarchy reflect what really happens
instead of trying to save the user from typing a few more characters. Less
magic means developers understand the code better. It's a tradeoff worth
making.
Peppe
From: "ext [email protected]<mailto:[email protected]>"
<[email protected]<mailto:[email protected]>>
Date: Thu, 17 Mar 2011 07:38:43 +0000
To: <[email protected]<mailto:[email protected]>>
Subject: [Qt-qml] internal re-parenting of child items
Hi,
Is there any recommended patters how to handle internal re-parenting of child
items?
I’ll open up the scenario with a small example. Let’s take imaginary QML
components as Menu and MenuItem (both derived from QML Item). The idea would be
that the application developer would be able to write:
Menu {
id: optionsMenu
MenuItem {…}
MenuItem {…}
MenuItem {…}
}
To populate the menu. Internally the Menu would like to use QML Column element
as middle-man to layout the items as:
*Menu.qml*
Item {
default property alias content: layout.children
Column { id: layout; anchors.fill: parent }
}
This works like magic until someone wants to dynamically add another MenuItem:
var newMenuItem = new MenuItem(optionsMenu) // wrong parent!
or
menuItemComponent.creatObject(optionsMenu) // wrong parent!
This fails miserably and the only way this could be achieved is that the user
of the Menu component would know the internal structure and would be able to
write something nasty.
What would be the recommended pattern?
#1 never change the default property
#2 never mix’n’match static and dynamic allocation of child items
#3 expose middle-man as ‘container’ property which can be used in dynamic
allocation
#4 provide always functions to add/remove dynamic stuff
#5 re-parent dynamically added children to the middle-man inside the
onChildrenChanged
#6 let the user do the nasty bit – they can make it work if they really want to
#7 something else?
Thanks,
Pekka
_______________________________________________ Qt-qml mailing list
[email protected]<mailto:[email protected]>
http://lists.qt.nokia.com/mailman/listinfo/qt-qml
_______________________________________________
Qt-qml mailing list
[email protected]
http://lists.qt.nokia.com/mailman/listinfo/qt-qml
