@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
}
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
