> 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
Well, you can have a public or protected method instead, like
QString value(const QString &value) { return m_metadata.value(value); }
- Alex
-----------------------------------------------------------
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
>
>
_______________________________________________
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
