[Development] QTCS2019 Notes from QtQml session

[Filippo Cucchetto]

Having followed the evolution and first announcement of Qml/Quick QML3
seems like an admission of guilt.
I remember when a lot of people complained about the use of Javascript as a
scripting language and further
more on the lack of a public C++ API. Now it seems like some of the QML
problems are going to be fixed
but still i wonder if instead of putting man power in cutting QML2 we could
bring first citizen C++ QtQuick API.
Playing the devil's advocate why can't we leave QML2 as is and instead use
the new pseudo declarative
C++ syntax and code everything in C++? I mean...we want speed? you want
speed? use plain C++.

Il giorno lun 25 nov 2019 alle ore 22:06 Filippo Cucchetto <
filippocucchetto at gmail.com> ha scritto:

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


-- 
Filippo Cucchetto
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20191125/900f2a35/attachment-0001.html>