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. _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
