[Development] QML Runtime

[Koehne Kai]

> -----Original Message-----
> From: Alan Alpert [mailto:416365416c at gmail.com]
> Sent: Tuesday, January 08, 2013 5:43 PM
> To: Koehne Kai
> Cc: Sorvig Morten; development at qt-project.org
> Subject: Re: [Development] QML Runtime
> 
> [..]
> Technically you could achieve the same thing with one big binary instead of
> several smaller ones. I prefer the several smaller ones approach, because it's
> simpler and more efficient. You can technically use the runtime for
> development in the same way you use a webbrowser, but for serious QML
> development I think the answer will always be Qt Creator.

Well, at the end of the day the different runtime alternatives also will show up in Qt Creator (we e.g. offer to run a certain .qml file explicitly either by qmlscene or qmlviewer , since there's AFAIK no bullet-proof way to find out the right runtime by just looking at the file). But granted, we can make sure that the defaults are sane, so people usually just press run.

Still, we've already qmlviewer and qmlscene, now comes qml ... from the users perspective it would be good to have _one_ binary to rule 'em all :) 

> Note that if the qml binary works sufficiently for basic development as a
> more generic runtime, qmlscene and qmlviewer could theoretically move to
> Qt Creator (or go away, depending on what Qt Creator wants).

We had that before - Qt Creator still ships a pimped version of qmlviewer called qmlobserver that adds the debugging API that didn't make it in 4.7.x (but was added to QtDeclarative in 4.8.0). Anyhow, this caused quite some headache: The binary has to be compiled with the target Qt version, which is done semi-automatically from within Qt Creator, but for a lot of cases fails, e.g. for embedded targets. Another example was the original qmlplugindump, which was first part of Qt Creator. This too caused headache, so we moved it to Qt ... Really, I don't want to go back , these tools are much more bound to Qt than to Qt Creator (and could also be used by other IDE's too).

> As specialized development tools they should fit into the Qt Creator story
> properly. An example would be if we had a separate development tool for
> running QML it would be nice to integrate the performance profiler - like
> QtCreator has already done.

The profiler and debugger works out of the box for any QML application, with whatever runtime. The server part is part of QtQml/QtDeclarative, and the qmltooling/qmldbg_tcp plugins. So no additional work needed for this. 

Regards

Kai