[Interest] Building a large desktop application with QML/QtQuick?

[Bo Thorsen]

Hi Russel,

Den 19-06-2015 kl. 21:00 skrev Russell Warren:
> I'm contemplating making a large/monolothic/modular desktop application
> with QML/QtQuick.  The application would be a client-side application
> for a back-end server with a lot of data.  There will be a wide variety
> of interfaces to manage, including: many forms for creating/modifying
> various server-side objects; a large number of table/treeview displays
> for exploring data, and many varieties of interactive graphs/charts.
> Data viewing must scale up to millions of data points of diverse
> types... ListView, TableView, and the new TreeView controls would
> definitely be heavily used.  It is also worth saying that the control
> count/density would be pretty high. Portions of the application would be
> like an IDE, or like Excel (but JMP [1] is a better example).
>
> Starting proof of concepts with QML look really promising.  In
> particular, the GUI design/layout model is so enjoyable that reverting
> back to Qt Widgets development feels clunky and old (I hate to say
> that... I love Qt Widgets!).  QML works very nicely.  Binding on its own
> is awesome.
>
> However, before a more significant investment into the QtQuick path, I
> figured it was worth asking a few questions on this list:
>
>  1. Can anyone think of any fundamental reason to NOT do the interface
>     with QML? ie: Any compelling reasons that we should stick with
>     old-school Qt Widgets?

Yes, there are a lot of reasons. But also reasons for moving to QML. 
Here are some of the problems you will face:

1) Maintaining large QML applications seems to result in more bit-rot 
than widgets based code. Some of this comes from the language being much 
less structured

2) Refactoring QML code is much harder than refactoring C++ code

3) Avoid large QML file like the plague. I have inherited a customer 
application with a 5000 line QML file in. If it had been written 
properly in the first page, it should be at least 5 different files. But 
see 2) for the reason I haven't split it up

4) Performance of loading large QML application is bad, so you have to 
use loaders and other ways to minimize startup time. That makes the code 
harder to do

5) The language itself has the problem that there's no separation of 
data and presentation. You must make sure that this happens or you end 
up with massive problems

6) The JMP application looks like a desktop application. QML is ideal 
for making embedded application with custom look and feel. That's not 
what you are doing

7) Tooling of QML is still almost non existant, which for small 
application is less of an issue. But with a large one, printf debugging 
is really sad. GammaRay might help, but only for some sets of problems

8) The components are IMHO still only a toy (to me, if something is 90% 
done, it's not done). Those would have been perfect for you

>  2. Does anyone know of any existing examples of large applications
>     built with QtQuick?

Yes I have worked on several for different customers. Two desktop 
applications and the rest embedded applications.

I tend to say desktop applications should be done with widgets and 
embedded with QML. But the real split should be: Custom look'n'feel or 
stuff that runs on phones: QML. Standard office like applications: Widgets.

And of course then there are a long list of real pros and cons. Those 
are only the first guideline for the choice.

>  3. Does anyone know of any good resources on structuring large QtQuick
>     applications?

I did a talk on DevDays about that exact topic. It was called something 
like QML Judgement Day. You should be able to find the slides and the 
talk on the dev days site.

Bo Thorsen,
Director, Viking Software.

-- 
Viking Software
Qt and C++ developers for hire
http://www.vikingsoft.eu