Review Request 119079: Add utility function for loading all plugins from a given dir + easy accessor for metadata

[David Faure]

> On July 5, 2014, 9:33 a.m., David Faure wrote:
> > src/lib/plugin/kpluginmetadata.h, lines 204-205
> > <https://git.reviewboard.kde.org/r/119079/diff/3/?file=286685#file286685line204>
> >
> >     Make member vars private.
> >     
> >     It's not like deriving from a value class makes any sense anyway, and this makes future changes possible (as long as the object size doesn't change).
> 
> Alexander Richardson wrote:
>     I thought applications that have extra metadata keys could just extend this class to provide a getter for that.
>     
>     class FooPluginMetaData : public KPluginMetaData {
>     public:
>       using KPluginMetaData::KPluginMetaData;
>       QString fooBar() {
>         return m_metadata["X-Foo-BarInfo"];
>       }
>     }
>     
>     But I can make them private anyway if you think this is not a valid use-case
> 
> Alex Merry wrote:
>     Well, you can have a public or protected method instead, like
>     QString value(const QString &value) { return m_metadata.value(value); }

Deriving from KPluginMetaData just doesn't make sense. How would apps do that, when the API from KPluginLoader returns them a QVector<KPluginMetaData> in the first place? They could copy each item into something else, but then better use composition than inheritance for that "something else", to avoid any risk of slicing (= copying from derived to base and losing the derived stuff).
This is the same reason why inheriting from QString or any other value class is a very bad idea (TM).

Alex's suggestion sounds good, in any case (with a "const" before the '{') -- as long as the docu doesn't mention inheriting from KPluginMetaData, of course :)


> On July 5, 2014, 9:33 a.m., David Faure wrote:
> > src/lib/plugin/kpluginmetadata.cpp, line 30
> > <https://git.reviewboard.kde.org/r/119079/diff/3/?file=286686#file286686line30>
> >
> >     Not static global objects in libraries, they slow down application startup and can lead to issues due to the undefined order of creation/destruction.
> >     
> >     Use static const char[] here, and convert to QString at usage time.
> >     
> >     I guess 16-bit readonly data would be better, but I'm not confident about how to write that portably.
> 
> Alexander Richardson wrote:
>     Yeah thats right, I though QStringLiteral didn't cause a global constructor call, but clang -Wglobal-constructors proved me wrong.
>     
>     Since these keys are used only once (except for MetaData), I guess I could just get rid of those global statics and insert a QStringLiteral in the function that needs the string

Right.


- David


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/119079/#review61635
-----------------------------------------------------------


On July 5, 2014, 3:20 p.m., Alexander Richardson wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/119079/
> -----------------------------------------------------------
> 
> (Updated July 5, 2014, 3:20 p.m.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Repository: kcoreaddons
> 
> 
> Description
> -------
> 
> This class simplifies reading the metadata from a qt plugin by providing
> type safe accessor functions for the standard plugininfo keys that are
> also used by the .desktop file based KPluginInfo
> 
> KPluginMetaData: Read the translated value for name and description
> 
> The "Name" and "Comment" fields of the metadata should be translated
> since they will be shown to the user (e.g. in the plugin selection
> dialog)
> 
> Add a unit test for KPluginMetaData
> 
> 
> Add KPluginMetaData::findPlugins()
> 
> 
> Add a unit test for KPluginMetaData::findPlugins()
> 
> 
> Introduce KPluginLoader::instantiatePlugins() and add a unit test
> 
> This method allows easily instantiating all plugins in a given directory
> 
> KPluginMetaData::pluginName() was changed to return the base name of the
> plugin file if no plugin name was set in the JSON metadata
> 
> 
> Diffs
> -----
> 
>   autotests/CMakeLists.txt 75d12932b36fcfe4ae1d538176ef9f85f60f15dd 
>   autotests/kpluginloadertest.cpp c8225c02de3a64cae29d88954700dbc6f03ff1b0 
>   autotests/kpluginmetadatatest.cpp PRE-CREATION 
>   src/lib/CMakeLists.txt 26eb5a1d4d56742a3395ba2645290bea15aee181 
>   src/lib/plugin/kpluginloader.h 0b7a53d3b879cec1d755b849d9d8c640d251a379 
>   src/lib/plugin/kpluginloader.cpp 9b3c5b6aec537b03b0d8341b33f6f4d7a76c8344 
>   src/lib/plugin/kpluginmetadata.h PRE-CREATION 
>   src/lib/plugin/kpluginmetadata.cpp PRE-CREATION 
> 
> Diff: https://git.reviewboard.kde.org/r/119079/diff/
> 
> 
> Testing
> -------
> 
> Added a unit test
> 
> Should easily allow loading all plugins from a given directory without needing kbuildsycoca
> 
> 
> Thanks,
> 
> Alexander Richardson
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20140705/a2590bcd/attachment-0001.html>