[Development] Platform Content Selection

[Mohamed Fawzi]

On 16 Jan 2013, at 10:54, 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 ;) .

yup, initially We had another selection algorithm, but then I looked again at yours,
and found it better. The only think that I don't like so much is that the implementation
might scale quadratically with the number of selectors, but keeping an explicit
list of current matches, and shortcutting when empty/with only an element
(which should be most of the time), should speed it up.

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

The main reason we left it (and also a detailed selector definition) out
 is that as soon as you add libraries a problem comes in:
selectors are global, and if you allow user defined selectors
(which I am inclined to have), then one might have clashes
(same selector name used in a different way) when using several libraries

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

shorter yes, easier, I am not so sure, global search and replace
can work pretty well…

> 
> So we probably need to support relative urls.

I am not so sure about this, yes they have advantages, but I think
that it is possible also to live without them (they would clash with the
namespace proposal below).
> 
> 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 this last approach: I would use the first component of the url as namespace.
It would select a given directory, and a given set of selectors.
This way selectors are not global but connected to the given namespace.
The namespaced selectors should be prepended to the (hopefully few, and static only)
global selectors.

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

I find Alan's reason for "-" compelling, no reason to like "_" more it was just a choice we came up with.
> 
>>> 
>>> 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.

There is a problem if we want to apply this mechanism to the "normal"
imports
> 
>>> 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.

yes one could have a single translation function that accepts and "environment"
with the selectors, along with the string as arguments, and a global default environment.

>> 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
> 
> 
> 
> 
> 
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development