thanks Elvis, Filippo, Ulf,
now I know what to do the next months to make my apps QML3 - ready ;-)
yes - then my code will be better re-usable and cleaner as now
will blog about all those refactorings
ciao
ekke
Am 26.11.19 um 09:20 schrieb Elvis Stansvik:
> 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
