|
|
| Line 1: |
Line 1: |
| An <span class="caps">API</span> is needed to control <span class="caps">QML</span> imports, this allows for applications to use it as a scripting environment without windows popping up, or as part of platform security on platforms which provide a <span class="caps">QML</span> entry point. <br /> -should allow redirects for attempts at restricted use<br /> -should work even on ‘builtin’ modules<br /> -should not be applied in a default QQmlApplicationEngine, but be configurable on the engine
| |
|
| |
|
| This session aims to fill out the above list of requirements and decide on the <span class="caps">API</span>.
| |
|
| |
| Decision is that we’ll try to stick with the new QQmlAbstractUrlInterceptor. By redirecting the attempt to load the qmldir, to fallback implementation or to an invalid implementation (preferably with a qmlError() as well). Custom control can be added to a QQmlApplicationEngine at the C++ level fufilling most of the above needs (with the exception of being able to restrict built-in imports such as QtQml 2.0).
| |
|
| |
| One thing that might help would be to see if the current file or context could be made available to the QQmlAbstractUrlInterceptor.
| |