[Development] The place of QML

[Frank Hemer]

On Tuesday 08 May 2012 04:13:40 Alan Alpert wrote:
> 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.

Nice to hear that there will be qt-related tools in sight.
Still I'm used to develop with emacs for many years now. And I definitely do 
not want to be forced to use specific tools which imply new dependencies!

Frank