Den mån 25 nov. 2019 kl 22:08 skrev Filippo Cucchetto <filippocucche...@gmail.com>: > > @Ekke > I think you should redesign your qml the other way around. For your problem > there're multiple solutions > 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. > In this way you get the reference of the StackView from leaf nodes. > 2) Pass a StackView reference to the Page at the point of instantiation > Page1 { > id: page1 > view: stackView // used inside Page implementation > } > 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). > Instead your page should just expose signals or items. The wiring between > these signals and view is done outside. > For example instead of: > > // Page1,qml > Item { > Button { onClicked: stackView.doSomething() } // Reference StackView by > id..magically...awful!! > } > > Do like this > // Page1.qml > Item { > property alias loginButton: button > Button { id: button } > } > > // Somewhere.qml > > Page1 { > loginButton.onClicked: stackview.doSomething() // Logic outside view > }
I agree. An analog to this in Qt/C++ land would be doing something like auto foo = static_cast<ExpectedParent>(parent()); // Use foo in a child widget, which is certainly a code smell (making assumptions about the context). The changes suggested would hurt our code base a little, because I know we're guilty of this transgression in some places of our QML as well. But I think it's worth it and the changes needed would improve our code. Just my 2 cents. Elvis > > This solution allows Page1 to be just a view (like an old .ui file). > In other words Page1 interface implies that there's a button or a clicked > signal but you're free to connect its > clicked signal to a StackView or SwipeView since wiring is done outside it. > > A even better solution is to delegate this to a FSM > > Page1 { > loginButton.onClicked: fsm.login() > } > > And then use a state of the FSM for handling the current page of the StackView > > StackView { > currentPageComponent: { > if (fsm.loginState.active) { > return loginPageComponent > } else if (fsm.connectedState.active) { > return connectedState.Compononent > } > } > } > > Best regards, > > Filippo > > > Il giorno lun 25 nov 2019 alle ore 16:54 ekke <e...@ekkes-corner.org> ha > scritto: >> >> Am 25.11.19 um 15:53 schrieb Ulf Hermann: >> >> Yeah, that's going to make using QML in actual applications a whole lot >> >> harder. For instance, sometimes access to some root node is needed even >> >> from deep leaf files. Removing that capability is quite a drastic measure. >> > Yes, but the problems with this construct are the same as with generic >> > context properties: Your QML component requires some context that it >> > doesn't declare. Therefore your code is not reusable and brittle wrt >> > addition of properties in other places. >> >> ooooh :( >> >> because of my own project rules my code is re-usable through all my projects >> >> from discussions here I learned to use SingletonInstance which can >> replace the properties I set in my root (main.qml) >> >> but there are many other situations where I thinkl this won't help >> >> per ex >> >> main.qml --> StackView --> Page1 --> Page2 --> Popup >> >> from main there are some StackViews (+ Pages) switchedby Drawer >> >> Page1 or Page2 can be used on top of different StackViews >> >> there are some properties and functions from StackView used by Pages or >> Popup. Can access them via id because all my StackViews have same id >> >> any idea how this should be refactored for QML 3 without loosing all the >> cool flexibility ? >> >> > >> > Mind that all those dynamic lookups will still live on in QML 2, and we >> > will maintain QML 2 throughout Qt6. They just won't be valid in QML 3. >> >> of course my goal is to go to QML 3 >> >> ekke >> >> > >> > Ulf >> > _______________________________________________ >> > Development mailing list >> > Development@qt-project.org >> > https://lists.qt-project.org/listinfo/development >> >> _______________________________________________ >> Development mailing list >> Development@qt-project.org >> https://lists.qt-project.org/listinfo/development > > > > -- > Filippo Cucchetto > _______________________________________________ > Development mailing list > Development@qt-project.org > https://lists.qt-project.org/listinfo/development _______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development