[Development] The place of QML

André Pönitz andre.poenitz at mathematik.tu-chemnitz.de
Sun May 6 23:44:56 CEST 2012

On Mon, Apr 23, 2012 at 07:35:02AM +0000, lars.knoll at nokia.com wrote:
> [...] And who says that 100% of the code has to be C++?

Nobody reasonably wants that. But people like to have a choice, and
different people will base their choice on different factors.

> I bet you are also happily using Perl/python where it makes sense. .ui
> files in Qt 4.x are XML, yet nobody complains about these.
> Qt is about finding pragmatic solutions to problems. Yes it comes from
> a C++ heritage, but I don't see why we should limit ourselves to
> purely C++ if we can create better solutions to the problem.
> [...]  No, you should be using QML. [...]

A better language does not automatically translate into a better
solution. The currently envisioned use of QML as a hybrid (at edit
and(!) run time) severely impacts the choice of available tools
to handle ordinary tasks like editing, debugging, profiling, and
whatever else is typically needed to make an application fly.

With old .ui this was not much of a problem because (a) one could
not do much with it anyway i.e. could not get it wrong either, (b) it
had no runtime implications, no need for mixed debugging/profiling
(QUiLoader is not exactly popular), and (c) one could even opt for
not using it at all.

Now we suddenly have an easy to use, yet compulsory, Turing complete
language with essentially no support from off-the-shelf tools.

How are people supposed to handle that? Who is going to provide the
QML enabled substitutes to the emacs-visual studio-xcode-valgrind
-gdb-cdb-purify-doxygen-designer-whatever-tool-hotchpotch people are
happily using? What happens to people who cannot or do not want to
use substitutes? Who is going to support and maintain the substitutes?


More information about the Development mailing list