[Development] Platform Content Selection

Thomas Hartmann Thomas.Hartmann at digia.com
Wed Jan 16 10:54:12 CET 2013


Hi,

Am 16/01/2013 02:23, schrieb Alan Alpert:
> On Tue, Jan 15, 2013 at 8:22 AM, Mohamed Fawzi <Fawzi.Mohamed at digia.com> wrote:
>> I had a long discussion with Thomas, and we came up with yet another solution :)
>>
>> This is in a way closer to the initial mail of Alan:
>
> Very close actually. But with better integration for non-QML applications ;) .
>
>> 1) special place for application local stuff
>> 2) global ordered list of selectors
>
> I assume working out the details of the selectors would be a separate
> thread. Or did you have specific selectors in mind? The implementation
> is useful even if selectors aren't agreed on, because this sort of
> infrastructure is necessary for individual platforms to implement
> their selections tightly in QML.

No we did not work out the selectors in detail.

The static selectors should probably be based on the platform.
Android would define "android" and "touch".
IOS would define "ios" and "touch".
Windows would define "windows" and "desktop"

There might be platforms where touch/desktop is ambiguous or decided at 
runtime. (Think of Windows 8 and one of these tablet/netbook hybrids).

Those propably would define "windows RT" but no touch and no desktop.

For the dynamic/runtime selectors I think they should be expendable by 
users, since we cannot foresee all use cases.

We would provide some dynamic selectors like "retina" or the resolution 
("800x600").


>> 3) some selectors are static (probably from the make spec), other dynamic
>> 4) 2 URLs: direct access to local application stuff, and access with selectors
>
> I assume the selected content is also in the app local dir, but you
> have a special way to access it without tripping the selector code.
> Note that selector code, at least in the QML engine, can't be strictly
> limited to the running app's local dir, because QML modules might want
> to use selection too (on files in their plugin local dir).

Yes we identified this issue, too.
One quick idea was to use a ./ prefix to indicate that the resolution
is relative.
Actually also in the case of application code their might be cases where
a relative path is shorter/easier to maintain than an application 
specific absolute one.

So we probably need to support relative urls.

But I think encouraging one absolute directory for all the application 
specific data , that might eventually also support bundling, is the 
right way. In a way I see this very similar to qrc urls (starting with ":").

We could even allow including several directories. This makes lookup 
slightly harder and could lead to conflicts, but then every library 
would just use its name as a namespace. (e.g res:components/ and 
res:application/)


>> 5) selectors are appended to the file name before the extension, special separator "_" not valid in base file name
>
> We allow UTF8 URLs, I don't think there's a separator not valid in
> base file names for QML currently. But we could easily lock out a
> particular character once you turn this feature on.

If we enable the feature just for urls starting with e. g. "res:" we 
cannot break existing code. So using either "-" or "_" should be safe.

>>
>> As lookup lookup algorithm I would use what was proposed by Alan, *but* adding the selectors to the filename, before the extension, not as extra directory
>>
>> The main advantage of this is that we expect just *few* special files, all files are close and reorganising the directory structure is easy.
>
> It's not so great if there are many special files, I originally
> considered the difference between a file name distinction or a
> directory distinction and thought there wasn't any. Now I can see a
> real advantage to the file name approach though, when combined with
> the special separator we can drastically reduce the potential
> incompatibility!

Also it is a lot easier to maintain. Changing the directory structure 
would be a nightmare, otherwise. Also it is very easy to check all the 
variants a single file has, because they are not spread around in 
different directories.

> One problem with introducing this is that there's no runtime version
> selection of the QML language, so it could break existing applications
> (if we can't solve this problem it just becomes opt-in on the engine
> instance instead of appearing magically, which isn't a big loss). If
> we use a separator not valid in QML type names, like "-", then there
> will be no existing cases where someone already had a type named, for
> example, Foo-touch.qml. Then the conflict scope is greatly lessened.
> If we provide that direct access URL then the conflict scope is
> lessened even further and an effective workaround is provided (because
> the only time it's inconvenient to provide a URL is QML type
> selection). With that level of compatibility with existing QML, I
> think it could be turned on in QQmlApplicationEngine by default
> (existing deployed apps still aren't affected, but anyone brining
> their QML to the new creator templates would be).

If we limit this feature to urls stating with e.g. "res:" I do not see a 
problem. The selector should also work for file/directory imports.

This means the selector can also be applied to directories.
More precisely to the base name of a directory if the url is a 
directory, not to directories which just happen to be part of the path.

>> It is easy even without any IDE to quickly see how many "foo.jpg" version there are.
>> The use of url handlers make it easy to use this for everything, any resource, not just qml.
>>
>> If all static selectors are close, and also the current static selector, one can drop non used files.
>
> So I like Mohamed's suggestion. It's something the QML engine could
> enable, and should work well with C++ applications too. Not sure about
> the dynamic selectors, but that's another thread.
>
> To clarify the proposed implementation further, I assume the
> implementation has the following components:
> A) A function in Qt to translate relative paths into local application
> area paths
> B) A function in Qt to translate relative and absolute paths into
> local application area, selector-aware paths.
> C) QML engine integration so that URLs (including type and script
> URLs) can pass through that second function for easy content selection

My idea was to implement it like resources are implemented. So it would 
be a feature in Qt Core not limited to QML at all (and completely 
transparent for QML).
Since QAbstractFileEngine is deprecated in Qt 5, I do not know how 
feasible this is, but it would be still the preferred way from my side.

It would also allow (optional) bundling all resources into a single file 
during deployment, as a feature for the future (not in the first 
implementation).

I think we should continue to brainstorm and collect ideas, but I think 
this is the right direction.


Kind Regards,
Thomas Hartmann








More information about the Development mailing list