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

[Elvis Stansvik]

Hi Martin,

(and sorry in advance for the line breaks in the inline quotations of
your mail below, seems GMail mis-parsed something).

2016-03-22 22:38 GMT+01:00 Martin Leutelt <martin.leutelt at basyskom.com>:
> Von: Elvis Stansvik <elvstone at gmail.com>
> An: "interest at qt-project.org Interest" <interest at qt-project.org>
> Gesendet: 22.03.2016 20:19
> Betreff: Re: [Interest] Structuring of QML app as set of interlinked screens
> for maximum code reuse
>
> 2016-03-22 20:13 GMT+01:00 Elvis Stansvik <elvstone at gmail.com>:
>> 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
>>         ...
>>     }
>> }
>
> To clarify, think of NavBar as just another Rectangle in the example
> above. It's just a custom item with some common visual properties.
>
> Elvis
>
>>
>> And I'm now trying to find a good structure that will minimize
>> repetition of QML code.
>
>
> Since you already know that every screen will have two NavBars and
> separators
>
> why don't you use your current QML structure as a skeleton for the whole
> application?
>
> The content area could then be a thing that loads the 'pages' of your
> application. Take a
>
> look at elements like StackView, TabView and ListView (in combination with
> Loader as a delegate) which
>
> already provide a mechanism to navigate between (dynamic) content...

Thanks a lot for the pointers, I had been looking at StackView for
doing the navigation between pages (though see my question about Qt
Quick Controls below).

The approach you describe sounds good. I think the reason I didn't
think of it at first was that I didn't know about the possibility of
having my "pages" provide a model for use by the navigation bars (like
you describe further on). I'm completely new to Quick / QML, so still
learning the ropes.

>
>
>>
>> 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)?
>>
>
>
> The content of your NavBars could be defined by models (maybe either
> ListModel or
>
> something more advanced), at least that's what I would suggest. Either each
> 'page' of
>
> your application defines a model for both the upper and the lower NavBar and
> these
>
> models are then used to dynamically create the appropriate content OR your
>
> application switches the content of the NavBars based on whatever state the
> application
>
> is currently in.

That makes a lot of sense. My only question is: If my "pages" provide
the models to be used for the top/bottom navbar, where would I define
the behavior for the navigational items in the bars? (the actual
interlinking of pages so to speak).

Just to clarify: Some of the actions in these bars will not be
navigational in nature, but should perform an action.

Should I define some central state machine? I've understood by now
that each QML item actually has a state machine, but this is primarily
meant for the visual state of the item in question (?).

>
>
>> 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 think your example fits QML rather fine. Your application seems to be the
> typical
>
> page-based mobile application, only limited to key interaction instead of
> touch/mouse.

Yes, sorry, I didn't mean to suggest QML isn't up to the task. Just
that it's not meant to be used the way I (wrongly) envisioned it be
used :)

>
> The initial conception of the architecture might require a bit of thinking
> but as soon
>
> as you have that figured out the actual content of the application can be
> added very easily.

Right, I should probably start by thinking hard about this before I go
on to design further screens. The app will not be that big (~15
screens or so).

>
>
>> 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.
>>
>
>
> You might find several applications using the page-based approach for
> basically every
>
> mobile platform out there. For more code take a look at the examples that qt
> already provides,
>
> you'll be able to find bits and pieces that you can easily adapt to fit your
> needs (for example the
>
> qt quick controls gallery).

Yep, the examples are good, but they are just that, bits and pieces.
What I haven't found so far is a canonical example that shows how a
fullscreen page oriented app would be structured from a birds eye view
(especially how the central (visual) application state is managed).
But I'll get my hands dirty and see what I come up with.

Many of the mobile apps either make use of frameworks built on top of
Qt Quick (Sailfish, Ubuntu Phone, ...) or make use of component
libraries intended mostly for phone platforms.

Our use case is slightly different as I think we'll want to build or
own completely custom components, since we want to control the exact
appearance and behavior. One thing I did not mention is that the input
is actually a knob which you can turn and push, nothing else. So
essentially we have three keys to operate the machine (well, the door
sensor is another one, and will be used for input in some situations),
which makes for some interesting challenges since some (infrequent)
uses of the machine will involve entering numbers and letters (nothing
long, just some positions, angles and short alphanumeric IDs according
to predefined patterns). The machine is for mineral analysis of drill
cores.

Anyway, many thanks for your input!

Elvis

>
>
>> Cheers,
>> Elvis
> _______________________________________________
> Interest mailing list
> Interest at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest