[Qt-qml] Best practices, patterns, etc.

[henrik.hartz at nokia.com]

On 6. sep. 2010, at 15.49, ext Cornelius Hald wrote:

> Hi All,
> 
> I'm now at the point where I have some quite solid UI mockups with all
> code written in QML/JS. It is possible to click through the UI and see
> some static content. The next step now is to connect the QML part with a
> C++ part that I still have to write.
> 
> Before I start with C++ coding, I'm having some questions. They are less
> technical, but more of the best practices type.
> 
> 1) I would like to have a QML UI that is (almost) completely usable
> without the C++ backend. This way I could give the QML code to a
> designer and let him tweak and change the UI without him needing a
> compiler, the source code, etc.
> The data that is displayed would be, of course, static dummy data.
> Still, switching from screen to screen, selecting items, etc. should
> work without having the C++ code.
> 
> Is this reasonable or just a bad idea? If it's reasonable what are the
> recommended steps to come to such a design? Are there common pitfalls?

You should be able to provide dummydata easily - and you can potentially switch between real and dummy models based on wether the real model is undefined or not - using a ternary operator.

> 2) Lets assume 1) is the recommended approach. My idea is to introduce
> some QML data components. That way I'm hoping I can easily define the C
> ++ API.
> For example, lets say we have a component PersonScreen. This screen can
> show all informations about a person. To populate such a screen with
> concrete data we're creating a PersonData component like follows.
> 
> ----- Components -----
> PersonData {
>  property string firstName
>  property string lastName
>  property int birthday // unix timestamp :)
>  property real weight
>  property url image
> }
> 
> PersonScreen {
>  property PersonData data
>  property color backgroundColor
>  [...]
>  Text {
>    text: data.firstName + " " + data.lastName
>  }
>  [...]
> }
> 
> ----- Usage ------
> ExamplePersonData {
>  id: exPerson
>  firstName: "Peter"
>  lastName: "Jones"
>  birthday: 123456
>  weight: 80.12
>  image: http://example.com/peter.jpg
> }
> 
> PersonScreen {
>  data: exPerson
>  backgroundColor: "lightblue"
> }
> 
> Having something like the above, I hope I can create a PersonData C++
> class and simply replace the QML example data with real data coming from
> the C++ backend. Does this make sense?

Yes, and with dummyModel and nativeModel you would use;

ListView {
...
model: nativeModel==undefined ? dummyModel : nativeModel
}

> 3) The main navigation structure of my application is that I have
> screens and if I select something, a new screen slides in from the
> right. Much like the stackable windows in Maemo5. To realize this, I'm
> using a top level ListView with a VisualItemModel. The screens are
> loaded into the VisualItemModel using Loaders. So if I'm having a branch
> in my navigation flow, I will dynamically load screen A or screen B into
> the next slot of my model.
> 
> I also thought, that each screen can expose a property like "nextScreen"
> and whenever this changes the top level component would load this screen
> using a Loader and then scroll the view to the right.
> 
> Again, does this make sense or are there betters ways to do navigation
> between a number of screens?

Sounds sensible - and similar to what is implemented in the Qt Components page loader;

   http://gitorious.org/qt-components/qt-components/blobs/master/examples/meego/pages/main.qml

> 4) Currently my screens are simple QML components and it looks like the
> view elements in QML can only be created using C++. Would I gain
> anything from implementing my screens as views? If yes, is there some
> documentation about implementing a view?

You only use a QDeclarativeView as the App toplevel, and load QML files in this one;

   http://doc.qt.nokia.com/4.7-snapshot/qdeclarativeview.html#source-prop

more generally you can find a guide to using QML in C++ applications here

   http://doc.qt.nokia.com/4.7-snapshot/qtbinding.html

Generally, the Qt Quick starting page of the docs is pretty covering and should be helpful going forward

   http://doc.qt.nokia.com/4.7-snapshot/qtquick.html

> Ok, that's it for now :) Sorry for all those questions, I just would
> like to make sure that I understood the QML paradigm before I blindly
> run in the wrong direction.
> 
> If anyone can help me with some of those questions, it would be really
> great!
> 
> Thanks!
> Conny
> 
> 
> _______________________________________________
> Qt-qml mailing list
> Qt-qml at trolltech.com
> http://lists.trolltech.com/mailman/listinfo/qt-qml