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

[Alan Alpert]

On Wed, Aug 14, 2013 at 11:33 AM, Thiago Macieira
<thiago.macieira at intel.com> wrote:
> On quarta-feira, 14 de agosto de 2013 11:13:09, Alan Alpert wrote:
>> > yes, it *must* be extended. you must make the system find the plugins
>> > themselves, not the qmldir files.
>>
>> You've failed to convince me that this *must* happen. The current
>> system works fine, this change would not fix the statically linked
>> plugin case, and the only advantage I see is that we'd be able to use
>> the JSON metadata - which is another change without any clear
>> advantage. Considering the thread started by decrying 'work for the
>> sake of it' I think we need some compelling reasons to make that
>> change.
>
> This discussion is not constructive anymore.
>
> Alan, please explain what the QML engine needs when it finds a given import
> statement. Assume an "abstract could of plugins" and that you can get any
> information you'd like from that cloud.

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.

Plugins are not the only usecase though, we need to be able to load
modules which may contain a plugin, files, or both. You will never
turn all files into plugins, because there are important prototyping
and development use-cases where it needs to be all run-time
interpreted from human-editable files.

Possibly not relevant is the usecase of registering a module at the
C++ level, which does not involve loading plugins at all.

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.
- Can the module be located in local import paths?
--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)
- Does the import match the name/version of a registered, C++ module?
If so load the types registered in that module.
- Can the module be located in the remote import paths?
--Same process as local, except plugin loading is disabled.

*Current as of after the changes prototyped in
https://codereview.qt-project.org/#change,56431 are finished. It's
intending to make 5.2, but is still waiting on a performance test
(which I need to chase up) verifying that it is faster.

--
Alan Alpert