Difference between revisions of "Development/Tutorials/Services/Plugins"

Jump to: navigation, search
Line 19: Line 19:
  
 
== Creating a Plugin Interface Class ==
 
== Creating a Plugin Interface Class ==
 +
The main step 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).
 +
 +
<code cppqt>
 +
#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;
 +
 +
};
 +
</code>
  
 
== The Plugin Factory Macro ==
 
== The Plugin Factory Macro ==

Revision as of 15:16, 30 October 2008

Creating and Loading Plugins Using KService
Tutorial Series   Services
Previous   Traders: Querying the System
What's Next   n/a
Further Reading   n/a

Contents

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

  1. include <kxmlguiclient.h>
  2. 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;

};

The Plugin Factory Macro

Registering a Plugin Type

Registering a Plugin With the SyCoCa

Finding Plugins

Instantiating Plugins


KDE® and the K Desktop Environment® logo are registered trademarks of KDE e.V.Legal