[Development] QML Runtime

[Alan Alpert]

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.

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).

--
Alan Alpert