Теперь мы переходим к самому интересному.
Для того, что бы наш плагин мог иметь свои плагины необходимо отнаследовать его от интерфейса IPluginReady и переопределить методы, которые необходимо.
Вот эти 2 метода (согласно документации):
QSet< QByteArray > GetExpectedPluginClasses () const - Returns the expected second level plugins' classes expected by this first-level plugin.
void AddPlugin (QObject *plugin) - Adds second-level plugin to this one.
На самом деле мне из этой документации ни черта не понятно, что и как надо делать. Но после разбора исходников других классов и консультации с лиддевом стало ясно. И так что должен возвращать первый метод? На самом деле любой QSet . Все что угодно, но при одном условии - все плагины для этого плагина должны возвращать один из этих QByteArray из своего метода
QSet< QByteArray > GetPluginClasses () const. Для удобства я вынес все эти методы в Core. Тоесть добил 2 метода в Core:
copy to clipboard
подсветка кода - QSet GetExpectedPluginClasses () const;
- void AddPlugin (QObject*);
И теперь вызов в Plugin выглядит так:
opy to clipboard
подсветка кода - QSet Plugin::GetExpectedPluginClasses () const
- {
- return Core::Instance ().GetExpectedPluginClasses ();
- }
-
- void Plugin::AddPlugin (QObject *plugin)
- {
- Core::Instance ().AddPlugin (plugin);
- }
Реализация Core::GetExpectedPluginClasses будет возвращать QSet с одной записью:
copy to clipboard
подсветка кода - QSet Core::GetExpectedPluginClasses () const
- {
- QSet classes;
- classes << "org.LeechCraft.Plugins.Poshuku.Plugins.OnlineBookmarks.IGeneralPlugin";
- return classes;
- }
Тоесть мы сообщаем этим методом ядру личкрафтов, что все плагины, которые из QSet< QByteArray > GetPluginClasses () const возвращают строку "org.LeechCraft.Plugins.Poshuku.Plugins.OnlineBookmarks.IGeneralPlugin" являются плагинами для нашего плагина. Тоесть с этим вопросом все просто. Стоит писать только более-менее уникальные строки, что бы была малая вероятность повторения.
Второй метод нужна для того, что бы хранить весь спиоск загруженным плагинов в нашем плагине для доступа к ним.
Можно сделать просто -завести в Core QObjectList и хранить в нем все плагины, но по рекомендации лидедва стоит создать класс PluginManager, которые будет наследоваться от BaseHookConnector и даст возможность хукать какие-то действия. Если вам не нужны хуки сегодня, то не факт, что не понадобятся завтра, так что я согласен с данным решением.
Класс PlguinManger очень просто и выглядит так:
copy to clipboard
подсветка кода - #ifndef PLUGINS_POSHUKU_PLUGINS_ONLINEBOOKMARKS_PLUGINMANAGER_H
- #define PLUGINS_POSHUKU_PLUGINS_ONLINEBOOKMARKS_PLUGINMANAGER_H
-
- #include
-
- namespace LeechCraft
- {
- namespace Poshuku
- {
- namespace OnlineBookmarks
- {
- class PluginManager : public Util::BaseHookInterconnector
- {
- Q_OBJECT
- public:
- PluginManager (QObject* = 0);
- virtual void AddPlugin (QObject*);
- };
- }
- }
- }
-
- #endif // PLUGINS_POSHUKU_PLUGINS_ONLINEBOOKMARKS_PLUGINMANAGER_H
Реалиация в нем еще проще:\
copy to clipboard
подсветка кода - #include "pluginmanager.h"
-
- namespace LeechCraft
- {
- namespace Poshuku
- {
- namespace OnlineBookmarks
- {
- PluginManager::PluginManager (QObject *parent)
- : Util::BaseHookInterconnector (parent)
- {
- }
-
- void PluginManager::AddPlugin (QObject *plugin)
- {
- Util::BaseHookInterconnector::AddPlugin (plugin);
- }
- }
- }
- }
Так как на данный момент нам не нужны хуки, то и зацикливаться на них мы не будем, а реализуем метода Core::AddPlugin :
copy to clipboard
подсветка кода - void Core::AddPlugin (QObject *plugin)
- {
- PluginManager_->AddPlugin (plugin);
- }
Вот и все. Теперь наш плагин может иметь свои же плагины. Созданием своего плагина для плагина мы займемся в следующем посту.