[Development] Platform Content Selection

Alan Alpert 416365416c at gmail.com
Wed Jan 16 02:23:07 CET 2013


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.

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

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

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

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

> 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

--
Alan Alpert



More information about the Development mailing list