[Development] The place of QML

[Alan Alpert]

On Mon, 7 May 2012 07:44:56 ext André Pönitz wrote:
> 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.

It's this "compulsory" part that I don't understand. The current situation is 
that if you don't want to use QML you don't use it. I understand that we're 
talking about transitioning to QML as the primary tool for UIs in Qt5, but 
that's both merely 'primary', and also very in-progress (don't make me copy in 
a boiler-plate "forward-looking statements" disclaimer ;) ). So these accurate 
holes that people are pointing out are issues that should be resolved over the 
Qt 5.x lifetime and only then, at the end of the journey, is QML going to be 
the only viable option.

Obviously I think QML is viable now, but I've thought that for years. Over 
those years I've watched it progress from where I'd seriously suggest it for 
10% of applications to where I'd seriously suggest it for 60% of applications. 
Once it grows to me thinking 100% of applications should use it (I'll probably 
be the first one to think this, if not the only one ;)) then we can talk about 
compulsory. I'd hope to reach that point around Qt 5.2, maybe 5.3.
 
> 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?

The Qt SDK already is starting to contain profiling and debugging tools for 
QML. So there's where and how they'll be provided/maintained.

-- 
Alan Alpert
Senior Engineer
Nokia, Qt Development Frameworks