Development/Tutorials/Services/Plugins
Development/Tutorials/Services/Plugins
Languages: عربي | Asturianu | Català | Česky | Kaszëbsczi | Dansk | Deutsch | English | Esperanto | Español | Eesti | فارسی | Suomi | Français | Galego | Italiano | 日本語 | 한국어 | Norwegian | Polski | Português Brasileiro | Română | Русский | Svenska | Slovenčina | Slovenščina | српски | Türkçe | Tiếng Việt | Українська | 简体中文 | 繁體中文
Tutorial Series | Services |
Previous | Traders: Querying the System |
What's Next | n/a |
Further Reading | n/a |
Abstract
Before starting with the code let's see which advantages we can undertake developing a plugin structured application. First of all an application capable of managing plugins can extend its features with apparently no limits. Anyway, rather than developing a plugin structured application because "it's so coool!!" the developer should think about the real advantages of this kind of development. For instance we can think about an archive manager application: the main program can delegate the creation/extraction/editing of each type of archive to specific plugins. This way we give modularity to the application so that supporting brand new archive types in the future will simply consist in writing the specific plugin and not rewriting the whole application. Ok, then let's stop talking.. and start coding =).
The Text Editor Example
So, even if an archiving application would be nicer to look at, here we will examine a simple text editing application capable of plugin loading. Each plugin will simply give a specific text editing feature.
Creating a Plugin Interface Class
The main step in order to create a plugin structure is to define its base class. This class will be inherited by every plugin and should give access to the key resources of the main application. In this example the main plugin class will inherit a KXMLGUIClient since every plugin will give access to its features through a gui element (a KAction in this case).
- include <kdemacros.h>
- include <kxmlguiclient.h>
- include <QObject>
class KTextEdit;
class KDE_EXPORT Plugin : public QObject , public KXMLGUIClient
{
Q_OBJECT
public:
Plugin(QObject *parent);
virtual ~Plugin();
/**
* @return KTextEdit pointing to the main application editor widget
*/
KTextEdit* editorInterface();
/**
* @internal Used by the main application to correctly set the editor.
* Do not call from within the reimplementation.
*/
void setEditorInterface(KTextEdit *);
private:
class PluginPrivate;
PluginPrivate *d;
};
This base class will give the useful pointers needed by each plugin in order to manipulate the main application data. In this case we only give access to the main editor interface through editorInterface().
The Plugin Factory Macro
Every plugin will be made "visible and available" through the use of a macro. So we better put this macro in our own myplugin_macros.h as follows.
- include <kdemacros.h>
- include <KPluginFactory>
- include <KPluginLoader>
- define TEXTEDITOR_PLUGIN_EXPORT( c ) \
K_PLUGIN_FACTORY( TextEditorFactory, registerPlugin< c >(); ) \
K_EXPORT_PLUGIN( TextEditorFactory("c") )