[Development] Platform Content Selection

[Alan Alpert]

On Wed, Jan 16, 2013 at 1:54 AM, Thomas Hartmann
<Thomas.Hartmann at digia.com> wrote:
> 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").

When you say dynamic selectors, do you mean selectors which are
determined at runtime or executed at runtime?

Determined at runtime, probably when the app starts up, and used in
the initial loading of the QML files will work fine. And app devs
could modify the stringlist if they need to.

Executed at runtime, as in changing from MyLayout-landscape.qml to
MyLayout-portrait.qml, won't work. At least not yet.

I'm fine with the former style of run-time selectors, but we'd need to
clarify that the 'runtime' selectors are still a fixed selection when
you evaluate URLs and not dynamic. It also makes them virtually
identical to the static selectors from a QML perspective.

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

I prefer the single directory (at least to start), because it's
trivial for applications to do multiple directories themselves once we
have that.  If you have an app content directory containing
"components" and "application" folders, it already works with
"res:components" and "res:application". On some platforms we might
have to bundle all the "multiple" directories into one single
application local directory anyways.

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

Yes, adding a selector scheme would be perfectly safe. My concern with
that approach is that
A) It makes it the exception, not the common case. Selection makes
sense as the common case because in practice, you won't have a
icon-369dpi.png unless you want to swap that out somehow.
B) It makes it incongruous with QML type selection, which doesn't have
a URL and so has to be implicitly res: (if the engine is so set).

Note that these arguments are about how it looks in QML. The QtCore
implementation could use res:, and QML could automatically prepend
that (if the engine is so set).

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

Usually the selector will have to be applied to types after directory
import. This is in order for it to also work with module imports and
the implicit import. Most QML files rely on the implicit import of the
current directory in order to find types, and it would be an
inconvenience to have to add import "res:." everywhere in order to get
the 'selected' types (basically, you'd lose all the convenience of the
implicit import).

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

QRC isn't completely transparent for QML, but it's easy to support.
The same could be done with res:. But what if you want to use both
resources and selectors? qrcres:?

--
Alan Alpert