[Development] QTCS2019 Notes from QtQml session

[Elvis Stansvik]

Den mån 25 nov. 2019 kl 22:08 skrev Filippo Cucchetto
<filippocucchetto at 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 <ekke at 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 at qt-project.org
>> > https://lists.qt-project.org/listinfo/development
>>
>> _______________________________________________
>> Development mailing list
>> Development at qt-project.org
>> https://lists.qt-project.org/listinfo/development
>
>
>
> --
> Filippo Cucchetto
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> https://lists.qt-project.org/listinfo/development