[Interest] Building a large desktop application with QML/QtQuick?
bo at vikingsoft.eu
Sun Jun 21 11:48:11 CEST 2015
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  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
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
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.
Director, Viking Software.
Qt and C++ developers for hire
More information about the Interest