[Development] QML Runtime

[Alan Alpert]

On Tue, Dec 11, 2012 at 4:53 AM, Shawn Rutledge
<shawn.rutledge at digia.com> wrote:
> I like all the ideas mentioned so far on this thread.  Here's a couple more:
>
> IMO there needs to be some QML 2 tool which adds back most of the features
> that qmlviewer already had.  They could be optionally-loaded plugins perhaps,
> but it shouldn't be a lot of trouble to start up the new viewer with those
> menus in place, and it shouldn't be a lot of trouble to leave out that
> functionality when you are just using it as a runtime.  So, maybe a short
> command-line option.  If there are to be plugins then the issue of a plugin
> path comes up, but one wouldn't want to be required to give the path every time
> when running the tool, so it would need to be persisted in some kind of settings.

It's not a lot of trouble, but I still don't like it. Maybe it could
go opt-in, like with a --debug-menu option, except that you don't
really want users activating that on your application and this might
make it too easy.

There's actually a lot more debugging functionality to qmlviewer (and
even qmlscene) than just the menus and screen shots. Run qmlscene
--help and you'll see a bunch of command line options. I don't think
any of them are relevant to the qml binary.

> It would also be nice to have one tool which can handle both QtQuick 1 and 2.
> So, maybe the qml tool should actually be a wrapper which loads _all_ its
> functionality via plugins, depending on what is needed.  That should make it
> fairly future-proof in case QtQuick 3 does something completely different again.
> If the wrapper does not assume that there is a GUI (only when you import QtQuick
> do you get the appropriate plugin), then this tool can also be used for writing
> non-graphical applications in QML; that's an area we haven't explored much yet,
> but JS has been used on the server side, so why not QML?

Loads all it's functionality using plugins... like QtQuick.Window 2.0?
I'm fairly confident that's the direction that a potential QtQuick 3
would go, that you will be able to load full scenes in QML 2 by
defining your window surface in QML too (just like QtQuick.Window). If
you add a QtQuick 1 loading plugin then you've got it all already.

Remember that imports are plugins, not just conceptually but also from
the loading arbitrary C++ code stance.

> On Windows I believe double-clicking a qml to launch the viewer in the
> simplest case is just like on Linux: the filename will be given to main's argv.
> You can do this already with qmlscene on Linux and Windows but not on the Mac.
> On the Mac, I believe the process is launched first, without extra options,
> and there must be an event loop running in order to receive the event
> asking it to open a specific file (QFileOpenEvent).
>
> http://doc.qt.digia.com/qq/qq12-mac-events.html (outdated but good explanation)
>
> So that's a wrinkle; I guess somehow the QApplication instance needs to be
> created early and then re-used for either QtQuick 1 or 2, or something like that.
>
> So in summary I think the ideal is to have the qml tool be very minimal, just
> capable of looking at the import statements and loading plugins, and then
> instantiating an Engine (in the case of QML 2).  There can be an extra command
> line for loading additional plugins, so the debugging features from qmlviewer
> can be broken up into more plugins which can be loaded if desired.  And
> there can be a user-specific config file (~/.qmlrc or some such) which
> specifies the extra plugins to be loaded when the user is running the tool
> standalone from a shell, as opposed to running it from an application
> launcher script.

What would a ~/.qmlrc file contain? And what plugins would need to be
loaded other than QML modules?

--
Alan Alpert