[Interest] Structuring of QML app as set of interlinked screens for maximum code reuse

Jason H jhihn at gmx.com
Wed Mar 23 14:50:30 CET 2016


You can inherit, with the higher level taking precedence, just like with polymorphism. I use this feature heavily, with great success.

You are correct, that there you should have a Screen.qml with common properties and elements. 
Then CustomScreen1.qml which contains a screen element, and other elements. 

For instance, I use one NavBar.qml which is in all my screens. The NavBar contains two of my StyledButton elements, and I use a custom StyledText Text element everywhere. For the final screen where Nav bar shows "Exit" instead of "Next" I just set a property. 

Finally, one last piece of advice, set your main element up as main.qml 
Window {
StackView {}
Screen1 {}
Screen2 {}
Screen3 {}
}

Have each screen emit navigation signals, and let your main decide what to do on the StackView: 
Screen1 {
  onNext: stackView.push(screen2)
}

But do add screen-specific functions to each Screen to keep them logical components. I'd not put those functions in main:
Screen1 {
  onAction: someScreenSpecificFunction(); // a function in main.qml 
}

That will just lead to confusion. Unless that invocation depends on other variables at the main.qml level.



> Sent: Tuesday, March 22, 2016 at 3:13 PM
> From: "Elvis Stansvik" <elvstone at gmail.com>
> To: "interest at qt-project.org Interest" <interest at qt-project.org>
> Subject: [Interest] Structuring of QML app as set of interlinked screens for maximum code reuse
>
> Hi all,
> 
> I'm working on a fullscreen Qt Quick/QML app (for machine control)
> which will consist of a set of interlinked screens, with key presses
> as the only interaction method.
> 
> Each screen will have roughly the following QML structure:
> 
> Rectangle {
> 
>     NavBar {
>         id: topBar
>         ...
>         controls for navigation and information stuff,
>         different depending on which screen
>         ...
>     }
> 
>     Rectangle {
>         id: topSeparator
>         ...
>         aesthetic divider rectangle between top nav bar and content.
>         ...
>     }
> 
>     Rectangle {
>         id: content
>         ...
>         main content here, different depending on which screen.
>         ...
>     }
> 
>     Rectangle {
>         id: bottomSeparator
>         ...
>         aesthetic divider rectangle between top nav bar and content.
>         ...
>     }
> 
>     NavBar {
>         id: bottomBar
>         ...
>         controls for navigation and information stuff,
>         different depending on which screen
>         ...
>     }
> }
> 
> And I'm now trying to find a good structure that will minimize
> repetition of QML code.
> 
> I understand that QMLs main model for code reuse is composition, but
> that it also has a form of "inheritance": by defining a new Item in a
> separate file using another Item as the top level item and redefining
> some of its properties, I'm sort of inheriting that item.
> 
> I could save the above general structure in a Screen.qml, and in
> FooScreen.qml, BarScreen et.c. do:
> 
> Screen {
>     ...
>     override some properties
>     ...
> }
> 
> But this will only allow me to redefine properties, and add new child
> items. How would I then be able to define both which content goes in
> the main area (the content Rectangle in the "base" item) and in the
> two navigation bars (topBar and bottomBar Rectangles)?
> 
> It seems QML is not really meant to be used this way, and I'd have to
> essentially redefine these things in each of my screens, even if
> they'll all have the same general structure? There's no "template"
> mechanism so to speak?
> 
> I'm very thankful for any tips from people more experienced with Quick / QML.
> 
> And if you know of a well designed full screen QML app modeled as a
> set of interlinked screens with keyboard navigation, I'm idle ears.
> 
> Cheers,
> Elvis
> _______________________________________________
> Interest mailing list
> Interest at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest
> 



More information about the Interest mailing list