[Development] QML Runtime
Shawn Rutledge
shawn.rutledge at digia.com
Tue Dec 11 13:53:03 CET 2012
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 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?
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.
More information about the Development
mailing list