<div dir="ltr"><div>@Ekke</div><div>I think you should redesign your qml the other way around. For your problem there're multiple solutions</div><div>1) Use some sort of StackView.view attached property. This is *usually* implemented with a simple upward hierarchy lookup of the first instance of a StackView.</div><div>In this way you get the reference of the StackView from leaf nodes.</div><div>2) Pass a StackView reference  to the Page at the point of instantiation</div><div>Page1 {</div><div>   id: page1<br></div><div>   view: stackView // used inside Page implementation<br></div><div>}<br></div><div>3) JUST DO THE RIGHT THING. Your page qml should not have code that directly calls the the StackView (This couples the Page to know that there's a StackView).<br></div><div>Instead your page should just expose signals or items. The wiring between these signals and view is done outside. <br></div><div>For example instead of:</div><div><br></div><div>// Page1,qml<br></div><div>Item {</div><div>  Button { onClicked: stackView.doSomething() }  // Reference StackView by id..magically...awful!!<br></div><div>}</div><div><br></div><div>Do like this<br></div><div>// Page1.qml</div><div>Item {</div><div>  property alias loginButton: button</div><div>  Button { id: button }</div><div>}</div><div><br></div><div>// Somewhere.qml</div><div><br></div><div>Page1 {</div><div>   loginButton.onClicked: stackview.doSomething() // Logic outside view<br></div><div>}</div><div><br></div><div>This solution allows Page1 to be just a view (like an old .ui file). <br></div><div>In other words Page1 interface implies that there's a button or  a clicked signal but you're free to connect its <br></div><div>clicked signal to a StackView or SwipeView since wiring is done outside it.</div><div><br></div><div>A even better solution is to delegate this to a FSM</div><div><br></div><div>Page1 {</div><div>  loginButton.onClicked: fsm.login()<br></div><div>}</div><div><br></div><div>And then use a state of the FSM for handling the current page of the StackView</div><div><br></div><div>StackView {</div><div>  currentPageComponent: {</div><div>      if (fsm.loginState.active) {</div><div>           return loginPageComponent<br></div><div>      } else if (fsm.connectedState.active) {</div><div>          return connectedState.Compononent<br></div><div>     }<br></div><div>  }<br></div><div>}</div><div><br></div><div>Best regards,</div><div><br></div><div>Filippo<br></div><div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Il giorno lun 25 nov 2019 alle ore 16:54 ekke <<a href="mailto:ekke@ekkes-corner.org">ekke@ekkes-corner.org</a>> ha scritto:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Am 25.11.19 um 15:53 schrieb Ulf Hermann:<br>
>> Yeah, that's going to make using QML in actual applications a whole lot <br>
>> harder. For instance, sometimes access to some root node is needed even <br>
>> from deep leaf files. Removing that capability is quite a drastic measure.<br>
> Yes, but the problems with this construct are the same as with generic <br>
> context properties: Your QML component requires some context that it <br>
> doesn't declare. Therefore your code is not reusable and brittle wrt <br>
> addition of properties in other places.<br>
<br>
ooooh :(<br>
<br>
because of my own project rules my code is re-usable through all my projects<br>
<br>
from discussions here I learned to use SingletonInstance which can<br>
replace the properties I set in my root (main.qml)<br>
<br>
but there are many other situations where I thinkl this won't help<br>
<br>
per ex<br>
<br>
main.qml --> StackView --> Page1 --> Page2 --> Popup<br>
<br>
from main there are some StackViews (+ Pages) switchedby Drawer<br>
<br>
Page1 or Page2 can be used on top of different StackViews<br>
<br>
there are some properties and functions from StackView used by Pages or<br>
Popup. Can access them via id because all my StackViews have same id<br>
<br>
any idea how this should be refactored for QML 3 without loosing all the<br>
cool flexibility ?<br>
<br>
><br>
> Mind that all those dynamic lookups will still live on in QML 2, and we <br>
> will maintain QML 2 throughout Qt6. They just won't be valid in QML 3.<br>
<br>
of course my goal is to go to QML 3<br>
<br>
ekke<br>
<br>
><br>
> Ulf<br>
> _______________________________________________<br>
> Development mailing list<br>
> <a href="mailto:Development@qt-project.org" target="_blank">Development@qt-project.org</a><br>
> <a href="https://lists.qt-project.org/listinfo/development" rel="noreferrer" target="_blank">https://lists.qt-project.org/listinfo/development</a><br>
<br>
_______________________________________________<br>
Development mailing list<br>
<a href="mailto:Development@qt-project.org" target="_blank">Development@qt-project.org</a><br>
<a href="https://lists.qt-project.org/listinfo/development" rel="noreferrer" target="_blank">https://lists.qt-project.org/listinfo/development</a><br>
</blockquote></div><br clear="all"><br>-- <br><div dir="ltr" class="gmail_signature">Filippo Cucchetto</div></div>