[Development] QML Runtime

[Koehne Kai]

> -----Original Message-----
> From: Alan Alpert [mailto:416365416c at gmail.com]
> Sent: Thursday, January 10, 2013 5:11 PM
> To: Koehne Kai
> Cc: Sorvig Morten; development at qt-project.org
> Subject: Re: [Development] QML Runtime
> 
> On Wed, Jan 9, 2013 at 11:57 PM, Koehne Kai <Kai.Koehne at digia.com>
> wrote:
> >
> >
> >> -----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?).
> 
> The distinction is actually a little more subtle than just runtime vs debugging.
> You would never want to debug the very same app you use in the runtime
> with qmlscene. The runtime provides as much help as qmlscene does for
> debugging those apps (QML-only apps). qmlscene is for debugging the QML
> part of hybrid apps, because it DOES provide an implicit QQuickWindow and it
> DOES NOT provide the QML-only application conveniences (which might
> conflict with conveniences added by the C++ part of your hybrid application).
> 
> So the primary feature distinctions are as follows:
> qml - adds convenience functionality for QML-only applications (and supports
> all modules, incl. QtQuick 1 and QtQuick 2) qmlscene - adds an implicit
> QQuickWindow for the root item qmlviewer - adds an implicit
> QDeclarativeView for the root item.

Alright, but I'd expect qmlscene (if we keep it) to be able to preview the very same files that the qml tools can handle - including handling of the shebang line.

> We could easily add a plugin based mechanism for adding implicit root items
> for the qml tool (although that would be yet another plugin mechanism, it
> would be better to annotate the QDeclarativeItem/QQuickItem types in their
> plugins). Would that satisfy the consolidation perspective? In terms of which
> binary to consolidate to: it can't be qmlviewer because that's done, it
> shouldn't be qmlscene because the extra convenience functionality can
> break applications not expecting it (and the name).
>
> When running a QML-only application I'd prefer no implicit root items, it's
> better that users know what they're doing, but it's not a big deal. 
> Add that to qml and then applications which really don't want that convenience
> functionality during development write their own shell, because that's
> primarily the scenario where you have conflicting application functionality (so
> you'd want to provide that with your own shell anyways).

So your idea is to consolidate on one qml binary, effectively deprecating qmlviewer and qmlscene? Sounds like a plan. I don't think we've 'deprecated' binaries in Qt before, but I personally don't see a big problem even removing them from one version to the other (as long as e.g. Qt Creator get's enough time to handle this gracefully from an IDE perspective). If we're nice we'd keep the binaries around for 2 minor versions or so ...

Regards

Kai