On Wed, Jan 9, 2013 at 12:41 AM, Koehne Kai <[email protected]> wrote: >> -----Original Message----- >> From: Alan Alpert [mailto:[email protected]] >> Sent: Tuesday, January 08, 2013 5:43 PM >> To: Koehne Kai >> Cc: Sorvig Morten; [email protected] >> 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 :)
Which one? > >> 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. I know the implementation is in qtdeclarative, but the unified UI isn't. To use the profiler you need to run a separate tool to qmlviewer/scene and I don' think there a UI added for the debugging protocol at all in that repo. I doubt that users ever use this outside of an IDE (although you're right that other IDE's can use them - that's a big plus). -- Alan Alpert _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
