[Development] Platform Content Selection

[Alan Alpert]

On Wed, Jan 9, 2013 at 12:26 AM, Alberto Mardegan
<mardy at 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