Lexical parent would result into bad behavior with rendering order. Items
render themselves and children, making a packed Items with a
default property alias children: mySubitemId.children
Lead to this behavior and do the right thing. ListView, Drawer, TableView and
other complexe rendering would also have to render much before your item can be
the true child (many item in between). If you need to talk about lexical
parent, it would seem easy at first hand, but would be very complex when
assigning property by function with new Item created on the fly or even a
Loader, Repeater would be somehow weird (Repeater create object with parent as
his parent). What would you put into the lexical child property? the one into
the script file or the new real children?? it become ambiguous and can be very
wrong about what is really happening.
What would happen with something like this:
Screen
{
id: screen_
MyItem
{
}
}
property Component obj: MyOtherItem {}
function changeChildrens(){
var obj_instance = obj.createObject();
// Replace MyItem is no more a children and should get deleted since no
more used and is script owned
screen_.children = [obj_instance];
}
what would the lexical children do when changeChildrens() get called? Now that
would be really confusing.
-----Original Message-----
From: Jason H <jh...@gmx.com>
Sent: December 12, 2019 11:34 AM
To: Jérôme Godbout <godbo...@amotus.ca>
Cc: interestqt-project.org <interest@qt-project.org>
Subject: Re: RE: [Interest] When is parent not the parent?
I'm not using that screen, I am using a Screen.qml that is an Item.
My app has "Screens" in it whose visibility is controlled by the application
state. That's why I only want the Prox sensor active when the screen is active,
rather than wasting main thread power on things which need not be updated.
It is regrettable that this parenting detail is not more clear. I always
thought it was the visual parent, which is the lexical parent, save for some
rare exceptions. I think those exceptions can be made rarer still. Like why is
the parent of the Prox Sensor in the example QQuickRootItem(0xd20f94b0)? It
should be the Screen.qml Item. I don't understand why it has to be parented
this way? At the very least, i would expect to be told that the prox sensor
doesn't have a parent property, at which time I would be forced to name it
explicitly. That way I wouldn't at least be able to code it wrong and have it
"kind of work".
If I could suggest a resolution to the immediate case, it would to have QML
sensors have a parent property which is their visual parent? I don't know why
this can't be the case.
Next, perhaps we need a visualParent property or a objectParent property to
differentiate when it matters? At least then we can tell when the two are not
equal, and say that in the documentation.
But I think the worst case is what we have now where it gives you no indication
that it is not the lexical parent.
> Sent: Thursday, December 12, 2019 at 8:38 AM
> From: "Jérôme Godbout" <godbo...@amotus.ca>
> To: "Jason H" <jh...@gmx.com>, "interestqt-project.org"
> <interest@qt-project.org>
> Subject: RE: [Interest] When is parent not the parent?
>
> Quick question (punt intendended), why using Screen as object and not
> a Window element? Screen is an Attachement Object normally and
> therefore should not have children, it should not be used that way
> unless I'm missing something here, your Screen is the
> https://doc.qt.io/qt-5/qml-qtquick-window-screen.html
>
> This is also going to happen when the Item have the default as an alias to
> sub children and this make perfect sense on some Items. You should use the id
> directly, it will be more robust and striaght forward. They all have parent,
> since they are all (except basic type) QObject. The parent might just not
> what it seem on the first look, but the real parent is necessary for proper
> scaling sometime!
>
> -----Original Message-----
> From: Interest <interest-boun...@qt-project.org> On Behalf Of Jason H
> Sent: December 11, 2019 6:05 PM
> To: interestqt-project.org <interest@qt-project.org>
> Subject: [Interest] When is parent not the parent?
>
> A simple Screen item derived from Item whose visible is false:
>
> Screen {
> id: proxScreen
> property int distanceEvents: 0
> property string lastValue: "Far"
>
> ProximitySensor {
> id: proximity
> active:parent.visible
> }
> }
>
> When I change the line:
> active: parent.visible
> to:
> active: proxScreen.visible
>
> The behavior changes. When it is referencing it as parent, the proximity
> sensor is active. When I use proxScreen instead, it is not active.
> "
> Reading up on this, it seems to be because parent refers only to the "visual
> parent". Which, I think is fine. The parent of the ProximitySensor is an
> Item, it has a visual parent. However this doesn't seem to be the case
> because ProximitySensor is not an Item itself so regardless of it's parent
> being a "visual parent". Therefore the docs are wrong, misleading or
> confusing.
>
> How much would it break things of we just made everything that is a child of
> something have a parent? I think it's completely reasonable to say (as I
> attempted to above) that this thins is only active when its parent is
> visible. I don't know how or what was being resolved as it's parent. I would
> have expected a "property not found" error or something, but I didn't get
> that.
>
> Given this kind of error, I suggest we just let everything have a parent,
> visual or not. It's unnatural to have so many things have a parent, and some
> others not.
>
> Thoughts?
>
>
>
> _______________________________________________
> Interest mailing list
> Interest@qt-project.org
> https://lists.qt-project.org/listinfo/interest
>
_______________________________________________
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest
