[Development] Qml what for, was Platform Content Selection

[Mohamed Fawzi]

On 9 Jan 2013, at 22:30, André Pönitz <andre.poenitz at mathematik.tu-chemnitz.de> wrote:

> […]
> A few questions that come to mind are:

I think these are good provocative questions, and I will try to answer them with
my personal opinion.
> 
> - Which real world problems do we address? [By "real world" I
>   explicitly do include handset makers, and potential single-
>   platform interest in that area, but it's definitely not
>   restricted to those]

Dynamic interfaces, with transitions and generally lot of dynamic layout.
This is relevant especially for touch devices.
> 
> - Given the just identified problems we want to solve, what are
>   the possible options to solve them? 

I think the pipeline of old style widgets is not adapted for this task I think.
Still a similar approach (with a stricter UI/Code separation) could work.
Apple for example went with that road.
Qt now has a new pipeline for getting graphics and UI to the screen, but as far as I know
no work is done to have a more "widget like" approach.

QML allows rapid prototyping and easy editing. Personally I find it sometime blurs
the ui/code line a bit too much, but with some care I think it is a good solution for the problem.
Some extra constraints could be added to it without breaking what is nice in my opinion

HTML5 can also be used for this purpose.
It shares several advantages/drawbacks with QML, because 
conceptually the approach is similar.
The main differences
 * it has a *much* larger developer/market share
 * it was not developed for this purpose, but is more and more used for that
 * Is cumbersome to write by hand, but many tools for it exist

> 
> - Assuming that QML is one of those options, where does
>   it _theoretically_ rank in terms of 
>    * implementation effort on the Qt side
>    * maintenance 

QML requires a much larger effort than the other options.
Lots has already been invested, and extra effort is still required
Having javascript in particular turned out to be a large dependency
with all sort of issues, that makes for example iOS port problematic.
All is being addressed, still it requires some effort.

>    * utility for the users

I think it is useful for those wanting to develop those kind of interfaces

>    * migration cost for the users

quite large, having desktop widgets libraries will help.
QML *can* be used a bit like widgets, with such a library.
I have no experience of porting normal applications, but I
suspect the in most cases it might not be worth the effort.

For *new* things, the major obstacle is to learn javascript and QML,
and how to use that effectively, so basically the fact that it is new
> 
> - Same as previous question: What's the actual state?
>    * what kind of effort is needed to make it "smooth"
>      from a developer point of view?

>    * what kind of maintenance effort do we face in the
>      long term?
>    * are users happy with it?
>    * how much effort did it take them to migrate?

Work is still needed, QtQuick 1 is usable, QtQuick 2 just shipped.
There are stumbling blocks, and things that could be better,
for example iOS, Designer for QtQuick 2,…
Still it can be used, and work is ongoing to address the problems

And qml *is* used, and there are happy users despite all shortcomings.
Especially for the early adopters there was some pain involved, but things
ar ok in the end.
(at least that is my perception without having done any survey).

Is Qml worth the effort, as said personally, while I don't necessarily share
all design decisions I think that the answer is yes, and I think that QML
while it can be misused, it can also be used effectively, and we are learning 
how to do it.

An important use case of Qml (smarphones,…) means that the UI
has to be adapted at the space available.
Thus being able to cleanly use a different layouts/ resources  is good.
Note that this pushes one toward a bigger separation between View and controller,
QML and javascript. In fact speaking with developers some are already doing
that, moving most of the javascript to a separate file.

Qml can be cross platform, specific optimisation for a given form factor or platform
should remain the exception (that is the reason I like the approach with user editable
platform dependent paths that can override just a few files on a given platform).

Fawzi