[Development] Plugin loader for Qt 5

[lars.knoll at nokia.com]

On 2/5/12 4:38 PM, "ext Thiago Macieira" <thiago.macieira at intel.com> wrote:

>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.

Which also means I'll try to implement this with the exception of the
second proposal. Not a problem IMO, as we can easily add Thiago's macro
later on with a different name if we so want.
>
>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.

I think we should delay this to 5.1. I can implement this now in a way
that won't block multiple entry points later on.

Cheers,
Lars