On Tue, Dec 11, 2012 at 4:53 AM, Shawn Rutledge <[email protected]> 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 _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
