[Development] QML Runtime

Koehne Kai Kai.Koehne at digia.com
Thu Jan 10 08:57:24 CET 2013



> -----Original Message-----
> From: Alan Alpert [mailto:416365416c at gmail.com]
> Sent: Wednesday, January 09, 2013 4:11 PM
> To: Koehne Kai
> Cc: Sorvig Morten; development at qt-project.org
> Subject: Re: [Development] QML Runtime
> 
> On Wed, Jan 9, 2013 at 12:41 AM, Koehne Kai <Kai.Koehne at digia.com>
> wrote:
> >> -----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 :)
> 
> 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



More information about the Development mailing list