[Development] Plugin loader for Qt 5
thiago.macieira at intel.com
Sun Feb 5 16:38:20 CET 2012
Lars's email about the feature freeze included a line about the plugin
mechanism in Qt. I posted about this many moons ago but it's still unfinished.
Thanks to Brad, it at least has stopped using QSettings to cache information.
However, we still need to get some information from the plugins.
Our objectives are:
- no extra files need to be installed
- extensible meta-data can be saved
- meta-data can be obtained without *actually* loading the plugin
Our goal is to have the Qt image formats and bearer plugins (for example)
be loaded on-demand. In order to do that, we need to know what functionality
the plugin offers before we load it. We don't ever want to load 3 different
bearer managers (at most one of them works).
Discussing with Lars here at FOSDEM, we came to a suggestion to use moc to
generate the meta-data. Why?
- all plugins already need a Q_OBJECT object (the instance)
- moc can generate the extra information and no one will be the wiser, since
it's already run anyway on the file with the Q_OBJECT
- moc can generate binary data (for example, binary JSON) for QPluginLoader
to find, which is also fast to parse given the new QJsonDocument class
- we should store it in a special ELF (Unix), Mach-O (Mac OS X) or COFF
(Windows) section of the executable to make it easier to find at runtime
- we can get rid of QFactoryInterface (no longer needed)
With an extensible meta-data system, we do not need to define what meta-data a
plugin can contain. Instead, each plugin interface defines which meta-data it
wants the plugins to provide. For example, for the image formats we can have a
wildcard match ("*.jpg; *.JPG"), a list of MIME types and even a "magic"
To store this information in the plugin, we are proposing that moc parse an
extra macro (that expands to no C++ code in the point where you use it, like
Q_PROPERTY). It can have a format like so:
Lars proposes something like this:
Where the "description.json" file is found by moc next to the source file being
parsed. This file is a JSON-encoded description of the plugin, containing the
meta-data that the plugin interface expects.
I would prefer to have a few more items in that macro, so we can write the
mata-data at the point of declaration:
Q_PLUGIN_METADATA(key1 NUMBER 1 key2 NUMBER 2 key3 STRING "foo"
key4 FILE "hello.desktop" key5 JSON "hello.json")
That would allow, for example, to embed entire external files like .desktop
files. However, it's clearly a lot more work to be done and we need to be quick
with the remaining features. Lars says he does not have the time to implement
that part soon.
One question we have outstanding is that of multiple entry points. How do we
do that? Or should the function entry point names be simply part of the
metadata? Do we _really_ need this in 5.0 to make the feature useful, because
we can implement it in 5.1 without BC breakage.
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
Intel Sweden AB - Registration Number: 556189-6027
Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 190 bytes
Desc: This is a digitally signed message part.
More information about the Development