[Development] Platform Content Selection

Mohamed Fawzi Fawzi.Mohamed at digia.com
Wed Jan 9 16:27:21 CET 2013


The import path solution is exactly what I think looks like the best solution.
For the qrc approach, the "first wins" approach makes it more usable, still
I would like to see a more automatic approach.
About import/search path I would also prefer if they could be set though
a platform dependent file that is read at startup (and that has some
reasonable default for each platform).

I would not be so quick in discarding the runtime case: yes for sure it is
less common, and it might have extra limitations, still I can see use cases
that would benefit from this: high resolution vs low resolution, landscape vs
portrait, different form factors (7 inch vs 10 inch tablet, 4:3 vs 16:9,...).

That will probably be done on an application by application basis,
but it might be nice to support that if possible (stilll I agree that it is not
a priority).

Fawzi
________________________________________
From: development-bounces+fawzi.mohamed=digia.com at qt-project.org [development-bounces+fawzi.mohamed=digia.com at qt-project.org] on behalf of Alberto Mardegan [mardy at users.sourceforge.net]
Sent: Wednesday, January 09, 2013 9:26 AM
To: development
Subject: Re: [Development] Platform Content Selection

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).
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.

> 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.

>> 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.

I'm not saying that the other use-case does not exist, but I presume
it's not (and won't be) that common.

> We already have qmlmin that does that. You can run it on your files
> for deployment, but I advise against using it during development ;) .

Oh, I didn't know about it; I definitely need to try it out.

Ciao,
   Alberto

_______________________________________________
Development mailing list
Development at qt-project.org
http://lists.qt-project.org/mailman/listinfo/development



More information about the Development mailing list