On Wed, Jan 9, 2013 at 11:57 PM, Koehne Kai <[email protected]> wrote: > > >> -----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?).
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 _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
