[Development] Metadata for loading QML plugins (was: qmlbundle vs Qt Resource System)

Thiago Macieira thiago.macieira at intel.com
Thu Aug 15 20:23:41 CEST 2013


On quarta-feira, 14 de agosto de 2013 12:11:17, Alan Alpert wrote:
> Basically what the engine needs is to find the types loaded into that
> module URI/version. So either the plugins in that abstract cloud need
> to be all loaded (in the QML engine sense, primarily calling
> registerTypes) or the URI/version needs to be able to specify a plugin
> to load. So in that abstract cloud case we'd query the cloud to see if
> it has a plugin matching that URI/version, and load that one if we
> find it.

I'm not sure I followed you.

Is this the processing of the import statement? Or is this the instantiation 
of an object?

For example, if I have:

import Foo.Bar 1.0;
Foo {}

At what point do you want to run the plugin's code? I imagine it's during the 
import, but I could be wrong and the engine might not actually run anything 
until the type is instantiated.

We might be trying to solve two distinct problems here and not talking about 
the same thing...

> For additional context, here's the current* process for module imports
> (e.g. import QtQuick 2.0)
> 
> - Does the import match the name/version of a registered, protected,
> C++ module? If so load the types registered in that module.

You've lost me here. I have no clue what a protected module is, I don't know 
how you'd register one, and I don't know what you mean by "load the types".

> - Can the module be located in local import paths?

I imagine this is the "import Foo.Bar 1.0" statement above. The engine sees it 
and tries to determine if there's anything that can provide Foo.Bar 1.0. 
Correct?

> --Search for each import path for
> $PATH/Name/with/dots/converted/to/slashes/qmldir then
> $PATH/Name/with/dots/converted/to/slashes.MajorVersion/qmldir
> --If the qmldir is found, load the module (load the plugin, register
> types in the plugin, register types defined in the qmldir file)

Ok, this is one mechanism today. 

We're wondering if we can add a new mechanism. The plugin system can provide 
you with the contents of the qmldir file for you. You don't have to scan for 
it. 

The most basic query would be "give me all qmldir" and you'd find the one you 
want. A more elegant way is to store some key information outside the qmldir 
file, like the module name and version ("Foo.Bar" and 1.0).

> - Does the import match the name/version of a registered, C++ module?
> If so load the types registered in that module.

Lost me here again.

> - Can the module be located in the remote import paths?

Remote paths?

> --Same process as local, except plugin loading is disabled.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.qt-project.org/pipermail/development/attachments/20130815/9985d82f/attachment.sig>


More information about the Development mailing list