Plasma/conditionalQMLImports: Difference between revisions

From KDE Community Wiki
No edit summary
 
(6 intermediate revisions by 3 users not shown)
Line 1: Line 1:
= Likely Solution in QQmlEngine =
The following design is the result of a BoF at the Qt Contributor Summit 2013, Bilbao:
QQmlEngine::setUrlInterceptor(QQmlAbstractUrlInterceptor*)
QUrl QQmlAbstractUrlInterceptor::interceptUrl(url, type)
qmlError(activeLoader) << "needs more permissions";
Fallback components may be loaded instead
QQml(Abstract)UrlInterceptor is private API in 5.1, if it has users, it will become public API in Qt 5.2. This means we have until ~October to check and test wether this API is sufficient for our usecase and to make possible changes. After that, it's set in stone.
= Hook into "import" =
Plasma must be able to register some custom hook c++ code to be executed during the parsing of the "import" keywork in qml.
The relevant code is in bool QQmlTypeLoader::Blob::addImport(const QQmlScript::Import &import, QList<QQmlError> *errors) in qtdeclarative/src/qml/qml/qqmltypeloader.cpp. The bool return value is used to signal an error when loading fails or is denied. Access to certain internals will be required; this can be seen by the use of methods such as finalUrl(), locateQmlDirectory() and addLibraryImport() in the current code. Significant classes in the import loading include QQmlImportDatabase and QQmlImports.
The use of that is twofold: fallback imports and conditional imports.
=Fallback imports=
A subset of the Plasma components are platform specific (for instance optimized for touchscreens) but not all of them. We need a mechanism to be able to override an import directory with another one. Preferable files will be loaded from the other one, and fallback to the normal directory if not found.
This will permit having just few "touch specific" components files while sharing 90% of the components code across all platforms.
= Conditional imports =
= Conditional imports =
In order to restrict applications or components in general, a security mechanism is needed in Qt. The basic design should be the following:
== General Design ==
In order to restrict applications or components in general, a security mechanism is needed in Qt. This should be implemented in collaboration with upstream Qt The basic design should be the following:


* In the import code path, the import is either done right away (current case), or it uses an optional import policy agent, which checks if the application or component has sufficient privileges, and either allows or denies the import
* In the import code path, the import is either done right away (current case), or it uses an optional import policy agent, which checks if the application or component has sufficient privileges, and either allows or denies the import
* The policy agent is replacable, much like QNetworkAccessManager
* The policy agent is replaceable, much like QNetworkAccessManager: QQmlImportManager (?)
* import manager is kept minimal in Qt API, but flexible in reimplementation
* different policies for subsets of the scenegraph are possible, for example per plasmoid import restrictions
* detailed failure information import failures can be handled gracefully by the application
* import performance in current case should not suffer
* import performance in current case should not suffer


This obviously needs changes in Qt, and should be implemented in collaboration with upstream Qt.
== Plasma Implementation Bits ==
On the Plasma side, this needs  
* signing of Plasmoids and other components (clients)
* permission validation extensions in imports metadata
* client UI for validation feedback in Plasma/Shell package
* an implementation of QQmlImportManager using the above parts
 
== Performance Measuring ==
Ideas for evaluating performance with or without import manager:
* instrument a minimal binary that loads a QML file, measure load performance, measure performance with and without overridden QQmlImportManager
* Generate 10000 files that each import a bunch of modules, put them in a ListView, model: 10000
* Dynamically create those components with a bit of javascript, measure loading performance

Latest revision as of 12:58, 16 July 2013

Likely Solution in QQmlEngine

The following design is the result of a BoF at the Qt Contributor Summit 2013, Bilbao:

QQmlEngine::setUrlInterceptor(QQmlAbstractUrlInterceptor*)
QUrl QQmlAbstractUrlInterceptor::interceptUrl(url, type) 
qmlError(activeLoader) << "needs more permissions";

Fallback components may be loaded instead

QQml(Abstract)UrlInterceptor is private API in 5.1, if it has users, it will become public API in Qt 5.2. This means we have until ~October to check and test wether this API is sufficient for our usecase and to make possible changes. After that, it's set in stone.

Hook into "import"

Plasma must be able to register some custom hook c++ code to be executed during the parsing of the "import" keywork in qml.

The relevant code is in bool QQmlTypeLoader::Blob::addImport(const QQmlScript::Import &import, QList<QQmlError> *errors) in qtdeclarative/src/qml/qml/qqmltypeloader.cpp. The bool return value is used to signal an error when loading fails or is denied. Access to certain internals will be required; this can be seen by the use of methods such as finalUrl(), locateQmlDirectory() and addLibraryImport() in the current code. Significant classes in the import loading include QQmlImportDatabase and QQmlImports.

The use of that is twofold: fallback imports and conditional imports.

Fallback imports

A subset of the Plasma components are platform specific (for instance optimized for touchscreens) but not all of them. We need a mechanism to be able to override an import directory with another one. Preferable files will be loaded from the other one, and fallback to the normal directory if not found. This will permit having just few "touch specific" components files while sharing 90% of the components code across all platforms.

Conditional imports

General Design

In order to restrict applications or components in general, a security mechanism is needed in Qt. This should be implemented in collaboration with upstream Qt The basic design should be the following:

  • In the import code path, the import is either done right away (current case), or it uses an optional import policy agent, which checks if the application or component has sufficient privileges, and either allows or denies the import
  • The policy agent is replaceable, much like QNetworkAccessManager: QQmlImportManager (?)
  • import manager is kept minimal in Qt API, but flexible in reimplementation
  • different policies for subsets of the scenegraph are possible, for example per plasmoid import restrictions
  • detailed failure information import failures can be handled gracefully by the application
  • import performance in current case should not suffer

Plasma Implementation Bits

On the Plasma side, this needs

  • signing of Plasmoids and other components (clients)
  • permission validation extensions in imports metadata
  • client UI for validation feedback in Plasma/Shell package
  • an implementation of QQmlImportManager using the above parts

Performance Measuring

Ideas for evaluating performance with or without import manager:

  • instrument a minimal binary that loads a QML file, measure load performance, measure performance with and without overridden QQmlImportManager
  • Generate 10000 files that each import a bunch of modules, put them in a ListView, model: 10000
  • Dynamically create those components with a bit of javascript, measure loading performance