[Interest] Tired of QML

Shawn Rutledge Shawn.Rutledge at qt.io
Tue Apr 18 14:16:48 CEST 2017

> On 15 Apr 2017, at 15:59, Alexander Dyagilev <alervdvcw at gmail.com> 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.

More information about the Interest mailing list