Qt wiki will be updated on October 12th 2023 starting at 11:30 AM (EEST) and the maintenance will last around 2-3 hours. During the maintenance the site will be unavailable.

Qt-contributors-summit-2013-QML-import-control: Difference between revisions

From Qt Wiki
Jump to navigation Jump to search
(Add "cleanup" tag)
m (Categorize)
 
Line 1: Line 1:
{{Cleanup | reason=Auto-imported from ExpressionEngine.}}
{{Cleanup | reason=Auto-imported from ExpressionEngine.}}
 
[[Category:QtCS2013]]
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
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



Latest revision as of 17:23, 6 January 2017

This article may require cleanup to meet the Qt Wiki's quality standards. Reason: Auto-imported from ExpressionEngine.
Please improve this article if you can. Remove the {{cleanup}} tag and add this page to Updated pages list after it's clean.

An API is needed to control QML 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 QML entry point.
-should allow redirects for attempts at restricted use
-should work even on ‘builtin’ modules
-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 API.

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.