[Development] Plugin loader for Qt 5

[Thiago Macieira]

Hi all

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" 
header matcher.

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:
	Q_PLUGIN_METADATA(description.json)

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...
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/20120205/dd2fbd4f/attachment.sig>