[Development] Platform Content Selection

Mohamed Fawzi Fawzi.Mohamed at digia.com
Thu Jan 17 14:36:05 CET 2013


On 16 Jan 2013, at 18:14, Alan Alpert <416365416c at gmail.com> wrote:

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

yes that is the first thing I was thinking about, which covers the most common cases

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

yes *if* we allow the second type (and I think that it should wait)
then one has to be sure that changing them is like changing a property
(ie. a qml should never see them changing during a single evaluation).

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

I tend to agree, but in practice we might have at least two directories,
one for qt, one for the app, and we most likely want to use the selectors
also in the qt directory.
Still we might want to fix only the app directory for now to simplify things.
> 
>> 
>> 
>>>> 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).

I think that a selector scheme should be available in any case (actually two
schemes, so one can switch off selector resolving).
Then one can think about using one as default.

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

Optimising for the least writing, while good, is not always the best solution
If things are clear and logical, I personally don't find some extra typing
so annoying.
Still I agree that for example qml can make relative urls work, something
that in general is difficult (because the context is unclear).

>>>> 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:?

res: could look in arc first, then in a given directory, maybe with the
constraint that the first matching for directory(fullPath) wins
(so that one does not have to merge resources between the same
directory in different places).

Fawzi




More information about the Development mailing list