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

[Alan Alpert]

On Thu, Aug 15, 2013 at 1:36 AM, Oswald Buddenhagen
<oswald.buddenhagen at digia.com> wrote:
> On Wed, Aug 14, 2013 at 12:11:17PM -0700, Alan Alpert wrote:
>> On Wed, Aug 14, 2013 at 11:33 AM, Thiago Macieira <thiago.macieira at intel.com> wrote:
>> > 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.
>>
> what i don't get is why you are talking about uris to start with. to
> make that module cloud actually abstract, you can have at most relative
> uris. but what's the point? modules are typically identified via
> namespaces.with.dots or namespaces::with::colons or something like that.

We call something like "QtQuick.Controls" a URI. It can be imported
into a namespace e.g. "import QtQuick.Controls as TheControls".

>> 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.
>>
> that's an implementation detail and must be entirely transparent to the
> qml code.

Entirely transparent to the engine you mean? Ideally, yes. As for the
QML code the application writer can probably update it if needed. We
already have a bit of a visible distinction in that local code can use
directory imports instead of module imports for decreased overhead in
the interpreted file case.

>> Possibly not relevant is the usecase of registering a module at the
>> C++ level, which does not involve loading plugins at all.
>>
> indeed, not relevant at all. the registration of sources in the cloud is
> a meta operation that must lie outside the domain of the language
> itself.
>
> do you agree so far?
> do you understand how the proposed mechanisms (plugin meta data, rcc
> files, etc.) contribute to the solution?

No. I still don't see why plugin meta data is an improvement over the
existing qmldir, at least in the near future, and rcc/qmlbundle is
still an issue of purely future speculation.

--
Alan Alpert