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

Elvis Stansvik elvstone at gmail.com
Wed Mar 23 17:44:58 CET 2016


2016-03-23 17:40 GMT+01:00 Elvis Stansvik <elvstone at gmail.com>:
> 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).

And of course I forgot to include the question I referred to above. I
was going to ask: Do you think using Qt Quick Controls would be a good
idea for an app like this? I'm a bit hesitant as I know we'll want a
completely custom look, and in many cases probably a quite custom
behavior for making input (due to the limited input devices), and fear
that I'll have to shoehorn a lot of this look/behavior if using Quick
Controls (or another component library which makes a lot of
assumptions).

Elvis

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



More information about the Interest mailing list