On Wed, Jan 9, 2013 at 12:26 AM, Alberto Mardegan <ma...@users.sourceforge.net> wrote: > On 01/08/2013 06:54 PM, Alan Alpert wrote: >> Do you have an example of how this could be done? Specifically, >> something that could select a different settings.js file for SameGame >> without having to go through the C++ executable? > > If by "without having to go through the C++ executable" you mean that > the selection must happen without the help of the C++ part of the > application, then I don't think it's currently possible (but I also > don't see why you would want to put that constraint).
That constraint is so that you can develop cross platform applications in the following scenarios: A) The targeted platforms provide a launcher executable, like qmlviewer (or the proposed qml), leading to a generic C++ executable. B) The developer avoids touching C++ at all and just uses the pre-generated templates (either a generic cross-platform template or a different template per platform). While QML has many benefits for elite C++ developers, it also has the potential of having a user base with more diverse skill levels. > If instead you mean that the selection must happen at runtime, I didn't > test it myself but I think it should be doable by just doing something > like this: > > ================ > QString platform = ...detect the platform... > QQmlEngine::addImportPath(basePath + platform); > ================ > > As far as I understand, a .js file is like a QML module, and looked up > according to the import path. It is not. The import path is only used for "module" imports (imports without quotes). So if you did that then it could affect imports like this: import QtQuick.Components but it would not affect imports like this: import "content" import "." //the implicit import import "settings.js" as Settings It also would not affect loading of other content, such as graphical assets. By restricting selection to a very specific subset of what is likely to change, you're making people jump through hoops to form their data "right". An example of hoops is that the plasma package implementation doesn't work with C++ plugins. To import a C++ plugin per platform they need to create a QML file wrapping its functionality, place the QML file in its own directory (so you can use a relative import statement), and have that QML file load the plugin using a non plasmapackage: URL. They could use the import path trick as a workaround, but that's subverting the intended distinction between module and relative imports. > >> I'm glad to hear it works for you. How are you generating those QRC >> files? Manually? It depends on how varied your UI is per platform, but >> in the case where only a few files are different it sounds like >> significant overhead (less so in the most files are different case, >> but that's already easily solved with different main.qml files). If >> this was the solution, I think it would need to be a little more >> automated. > > Yes, I'm doing that by hand. What is not shown there is that there is a > common QRC file as well, which contains all the default QML files and > which gets added to RESOURCES *later* (so, resources seem to work like > the PATH environment variable, where the first components have > precedence over the latter). So, the platform-specific components are > just overrides to the default set, or additions. Ah, that makes it sound much more reasonable. Though I have to wonder how discoverable the feature of "QRC overrides" is. >>> It seems to me that this is a problem which can/should be solved at the >>> build system level. >> >> I had the impression that it shouldn't be solved at the build system >> level (even though it can be). That breaks QML as an interpreted >> language, which is a nice benefit for on-device development (among >> other things). > > I cannot see the benefit of doing the selection at run-time: you > certainly cannot run the same binary you use on the BB10 on the Nokia N9 > or on the desktop; and while in some cases you might run the same binary > in a desktop and in a x86 tablet, most of the time the packaging format > will differ anyway. And even if it were exactly the same, one might > still prefer to do the selection at build time, in order to avoid > shipping unwanted QML/JS files. This is the difference between development and shipping. In terms of the build used for shipping I agree, you want to do the selection at build time and you should have a different application binary for each platform. But for developing a QML application you don't have to use your application binary, and may not want to. For on device development you could get a generic qmlscene binary for the device and start prototyping from there. More likely you'll start prototyping on desktop and still be using the desktop binary, you're just starting to write the mobile UI. If you need to rebuild the application specially, even if it's just to enable runtime selection in the simulator on desktop, that slows down the development process. Final testing and final shipping should use your own application build for device, initial prototyping should not. > I'm not saying that the other use-case does not exist, but I presume > it's not (and won't be) that common. > I presume this other use-case is the common case. If only we had hard data... This makes me want to add a phone home feature in the engine so we can collect usage statistics :P . -- Alan Alpert _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
