[Interest] When is parent not the parent?

[Jason H]

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" <godboutj at amotus.ca>
> To: "Jason H" <jhihn at gmx.com>, "interestqt-project.org" <interest at 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-bounces at qt-project.org> On Behalf Of Jason H
> Sent: December 11, 2019 6:05 PM
> To: interestqt-project.org <interest at 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 at qt-project.org
> https://lists.qt-project.org/listinfo/interest
>