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

Oswald Buddenhagen oswald.buddenhagen at digia.com
Thu Aug 15 20:11:30 CEST 2013

On Thu, Aug 15, 2013 at 10:14:46AM -0700, Alan Alpert wrote:
> On Thu, Aug 15, 2013 at 1:36 AM, Oswald Buddenhagen <oswald.buddenhagen at digia.com> wrote:
> > what i don't get is why you are talking about uris to start with.
> We call something like "QtQuick.Controls" a URI. It can be imported
> into a namespace e.g. "import QtQuick.Controls as TheControls".
ehm. that's an abuse of the term.
"fully qualified {module|class} name" would be a more precise term.

> >> 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?
no, to the qml code.
the engine must know these details to be able to deliver the
abstraction, obviously.

> > 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.
plugin metadata is an improvement because it eliminates the extra file
and therefore makes the system more uniform an intuitive (all "compiled"
formats would have only one file - one plugin or rcc file to load, one
static plugin to link, etc.) without making it more expensive (as the
meta data can be quickly looked up without actually loading a plugin).

More information about the Development mailing list