On Tue, Jan 15, 2013 at 8:22 AM, Mohamed Fawzi <fawzi.moha...@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 _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
