Development/Tutorials/Services/Plugins: Difference between revisions

Revision as of 13:16, 27 February 2009

Development/Tutorials/Services/Plugins

Creating and Loading Plugins Using KService

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") )

Registering a Plugin Type

Registering a Plugin With the SyCoCa

Finding Plugins

Instantiating Plugins

@@ Line 22: / Line 22: @@
 == 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 shuld 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).
+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).
 <code cppqt>