[Development] QTCS2019 Notes from QtQml session

[Filippo Cucchetto]

@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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20191125/10e9f83b/attachment.html>