Ok Shawn, my confusion is perfect now.
Is it really the case that QQuickItem::parent is a different function than QObject::parent and if
"QQuickItem::parent is about placement in the scene." what is QQuickItem::parentItem then?
Regards,
Gunnar Roth
Gesendet: Dienstag, 18. April 2017 um 14:16 Uhr
Von: "Shawn Rutledge" <[email protected]>
An: "[email protected]" <[email protected]>
Betreff: Re: [Interest] Tired of QML
Von: "Shawn Rutledge" <[email protected]>
An: "[email protected]" <[email protected]>
Betreff: Re: [Interest] Tired of QML
> On 15 Apr 2017, at 15:59, Alexander Dyagilev <[email protected]> wrote:
> On 4/15/2017 4:37 PM, Oleg Evseev wrote:
>>
>> parent.header seems to be not accessible as preInfoColumnWidth initializes with 0. :(
>> Firstly, header property is not an item of header, but a component. headerItem property holds the header item created from the header component. Also parent.headerItem.preInfoColumnWidth will not work, cause delegate items will not be direct children of Listview.
>> parent.parent.headerItem.preInfoColumnWidth will work, but better use idListview.headerItem instead this mess of parents.
> Ohhh... That's what I was talking about. A more intuitive API or at least an explicit explanation for newbies in the docs would be appreciated..
“parent” is often not what you think it is… the parent item isn’t the same as what you declared when something like Flickable (and likewise ListView, because it inherits Flickable) creates a contentItem and reparents its “children" to that. Trips up newbies all the time.
Just to make it more confusing, a QQuickItem actually has two parents: its QObject parent and its QQuickItem::parentItem. Usually the QObject parent is not exposed in QML. Now if only we could be consistent that the QObject parent is the one that a newbie will expect it to be, and expose it somehow… but needing to have both of them available would also be confusing. Should we call them father and mother, or parent and syntacticParent, or what? If you want to take an Item out of its current context and reparent it somewhere else, you need to set the QQuickItem::parent (by assigning it in _javascript_, for example). So that’s the more useful parent to expose to QML… except for the occasional confusion that it causes when you want to bind to parent properties and don’t understand which item is the parent.
And just in case we aren’t consistent with newbie expectations about the QObject parent either, it will turn out there’s a reason: because the QObject parent is responsible to destroy the children when it is destroyed. That’s why we have both: QObject parent is all about memory management, and QQuickItem::parent is about placement in the scene.
Especially never use parent when working with QtQuick.Dialogs, because the dialog implementation varies across platforms.
_______________________________________________
Interest mailing list
[email protected]
http://lists.qt-project.org/mailman/listinfo/interest
_______________________________________________ Interest mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/interest
