[Development] QTCS2019 Notes from QtQml session

Filippo Cucchetto filippocucchetto at gmail.com
Mon Nov 25 22:06:34 CET 2019

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

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 {
  currentPageComponent: {
      if (fsm.loginState.active) {
           return loginPageComponent
      } else if (fsm.connectedState.active) {
          return connectedState.Compononent

Best regards,


Il giorno lun 25 nov 2019 alle ore 16:54 ekke <ekke at ekkes-corner.org> ha

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

More information about the Development mailing list