> -----Original Message----- > From: Alan Alpert [mailto:[email protected]] > Sent: Wednesday, January 09, 2013 4:11 PM > To: Koehne Kai > Cc: Sorvig Morten; [email protected] > Subject: Re: [Development] QML Runtime > > 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?
Ideally we'd have one, whatever it's called :) Now we kept the qmlviewer / qmlscene distinction, I guess for many reasons (Qt Quick1 being in 'done' state, qmlviewer having some legacy functionality that was a dead end (e.g. 'runtime' object), avoiding dependencies to two different libraries ...), and I'm okay with it. But I really want us to think hard before adding yet another similar tool. Any feature you add to a 'qml' tool (e.g. '#!' handling) you'll need to qmlscene too, since you probably also want to debug the very same app you are using at runtime . So what features of qmlscene is it exactly you definitely not want to have in a runtime tool (and can we maybe make these optional then, e.g. through a plugin mechanism?). > > > >> 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. > [...] Well, actually there's a qmlprofiler standalone client in qtdeclarative, but without a GUI. In theory it could of course get a GUI, but I don't see a lot of value in this: You can use Qt Creator just as a viewer to the trace files, if for some reason you cannot or do not want to use Qt Creator to profile your application in the first place. Regards Kai _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
