[Interest] Tired of QML

[Jérôme Godbout]

I agree with Shawn as the parent is not always trivial and I strongly
suggest you use an inspector like GammaRay
https://www.kdab.com/development-resources/qt-tools/gammaray/
to check the properties (parent, childrens...).

Make yourself some simple example and check them out. The Component,
Loader, Repeater , Instantiator are the different from syntax declaration
and you may want to understand them properly when using them. Component and
the instance of a Component are 2 different thing and the variables values
into their Context must be understand properly to help yourself. I also
suggest you try to play with reparenting of Items or make file Component
alias to sub items children and default property to see the power this and
why the parent sometime is not as trivial as it first seem but allow
complex underlying structure.

Once you do may find Qml pretty funny to use and pretty strong.

It's still a relatively young declarative scripting engine and you may lack
some basic features and functions at times, but they are easy to implement
into C++ (Qt.matrix4x4 operation, Qt.quaternion functions and the like).

[image: bodycad] <https://www.bodycad.com/>
Jerome Godbout
Software Developer
2035 rue du Haut-Bord, Québec, QC, Canada. G1N 4R7
T:  +1 418 527-1388
E: jerome at bodycad.com
www.bodycad.com

The contents of this email message and any attachments are intended solely
for the addressee(s) and may contain confidential and/or privileged
information and may be legally protected from disclosure. If you are not
the intended recipient of this message or their agent, or if this message
has been addressed to you in error, please immediately alert the sender by
reply email and then delete this message and any attachments. If you are
not the intended recipient, you are hereby notified that any use,
dissemination, copying, or storage of this message or its attachments is
strictly prohibited.

Le contenu de ce message et les pièces jointes sont destinés uniquement
pour le(s) destinataire(s) et peuvent contenir des informations
confidentielles et / ou privilégiées qui peuvent être protégées légalement
contre toute divulgation. Si vous n'êtes pas le destinataire de ce message
ou son agent, ou si ce message vous a été adressé par erreur, s’il vous
plaît avertir immédiatement l'expéditeur par courriel de réponse, puis
supprimer ce message et les pièces jointes. Si vous n'êtes pas le
destinataire prévu, vous êtes par la présente informé que toute
utilisation, diffusion, copie, ou stockage de ce message ou de ses pièces
jointes est strictement interdit.

On Tue, Apr 18, 2017 at 8:16 AM, Shawn Rutledge <Shawn.Rutledge at qt.io>
wrote:

>
> > 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.
>
> _______________________________________________
> Interest mailing list
> Interest at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20170418/6a1ece73/attachment.html>