Bildbearbeitungs-Plugins für KDE entwickeln

Jede Anwendung ist eine Welt für sich. Dieser Satz gilt auch für die meisten Open-Source-Programme. Denn obwohl es logisch scheint, die Vorzüge von Programm A mit denen von Programm B zu kombinieren, bleiben Fusionen trotz Open Source und Basar-Theorie eher die Ausnahme. Eine davon ist die gemeinsame Plugin-Infrastruktur der KDE-Bildbearbeitungsprogramme Kphotoalbum alias Kimdaba [1], Digikam [2], Showimg [3] und Gwenview [4]. Dank der einheitlichen Schnittstelle arbeitet das KDE Imaging Plugin Interface (Kipi, [5]) unter allen vier KDE-Programmen. Kipi entlastet zudem die Hauptentwickler dieser Programme, da mit grundlegenden Kenntnissen in C++ jeder Programmierer Kipi-Plugins entwickeln kann.

Neues Kipi-Plugin

Der Artikel zeigt an einem Beispiel, welche Schritte zu einem neuen Kipi-Plugin führen. Das Plugin soll Bilder mit einem Wasserzeichen-Text versehen (Abbildung 1). Die Codeschnipsel und der Sourcecode des fertigen Plugins finden sich auf der Listing-Seite des Linux-Magazins [6] zum Download. Um das Plugin zu kompilieren, sind neben KDE und »libkipi« auch die zugehörigen Entwicklerpakete erforderlich.

Ein Kipi-Plugin entsteht aus folgenden Arbeitsschritten:

Abbildung 1: Das unfertige Beispiel-Plugin funktioniert bereits. Hier tippt der Benutzer den Text des Wasserzeichens ein und ändert die Schriftgröße.

• Das Plugin von der Klasse »KIPI::Plugin« ableiten
  und einige virtuelle Methoden überschreiben. Von dieser Klasse
  erzeugt die Host-Anwendung (zum Beispiel Gwenview) eine Instanz und
  kommuniziert damit.
• Informationen von der Host-Anwendung anfordern. Es existieren
  bereits einige Klassen, die Informationen zum aktuellen Fotoalbum,
  den gerade ausgewählten Bildern und zum Beispiel zu
  Schlüsselwörtern für ein bestimmtes Bild
  übermitteln.
• Zusammenarbeit mit dem Framework herstellen. Damit sie
  funktioniert, muss der Quellcode ein magisches Makro enthalten.
  Außerdem benötigt er ein »Makefile.am«, eine
  ».desktop«-Datei und einige weitere
  Framework-Dateien.

Schließlich muss der Programmierer noch den Code des eigentlichen Plugin schreiben.

Plugin-Klasse

Um ein Kipi-Plugin zu entwickeln, muss es der Entwickler von der Klasse »KIPI::Plugin« ableiten, die sich in der Include-Datei »libkipi/plugin.h« befindet. Listing 1 zeigt diese Klasse in einer gekürzten Fassung. Um ihre Funktionsweise zu verstehen, ist es wichtig, zu wissen, wie Host-Anwendungen Plugins laden. Mit Hilfe einiger KDE-internen Mechanismen findet die Anwendung sämtliche für sie relevante Plugins. KDE lädt die Plugins dynamisch, das heißt, es legt eine Instanz des Plugin an und übermittelt diese an die Host-Anwendung. Die Details dieses Vorgangs sind unter [7] näher beschrieben.

01 class Plugin : public QObject
02 {
03 public:
04     Plugin( KInstance* instance, QObject *parent, const char* name);
05     virtual void setup( QWidget* widget ) = 0;
06     KActionPtrList actions( QWidget* parent = 0 );
07     KActionCollection* actionCollection( QWidget* parent = 0 );
08     virtual Category category( KAction* action ) const = 0;
09 
10 protected:
11     void addAction( KAction* action );
12 }

Die Host-Anwendung ruft bei der Plugin-Instanz die »setup()«-Methode auf. Deren Aufgabe ist es, die nötigen »KAction«-Instanzen anzulegen. Interessierte Host-Anwendungen spiegeln die Actions in ihren Menüs ein - wo, das entscheidet die Anwendung, nicht das Plugin

Das Plugin muss von der Host-Anwendung erfahren, um welche Art von Erweiterung es sich handelt. Diese Informationen ermittelt die Host-Anwendung mit der »category()«-Methode. Damit der Ablauf reibungslos funktioniert, ist es nötig, dass das Plugin über »Plugin::actionCollection()« die »action«-Informationen der Host-Anwendungen sammelt und später für jede Aktion »Plugin::addAction()« aufruft. Dabei gilt es, zwei häufig Fehlerquellen zu vermeiden:

• Die »Plugin::actions()«-Methoden sind nicht
  für das Plugin relevant, sondern für die Host-Anwendung.
  Das API der Klasse betrifft hingegen das Plugin und die
  Host-Anwendung.
• Die explizite »setup()«-Methode ist nötig,
  weil das Plugin einerseits keine Kontrolle über die aktuellen
  Parameter des Konstruktors hat - den legt das
  KDE-Plugin-Framework automatisch an. Andererseits kann die
  Host-Anwendung das Plugin mehrfach einsetzen, zum Beispiel im
  Hauptmenü und im Kontextmenü.

Der Code benötigt deshalb mehrere »KAction«-Instanzen und ruft die »setup()«-Methode mehrmals mit verschiedenen Widgets als Argument auf. Listing 3 zeigt die vollständige Implementation der Plugin-Unterklasse.

Die Zeilen 1 und 2 binden das KDE-Plugin-Framework ein. »WatermarkPlugin« bezeichnet die Plugin-Klasse. Wer ein eigenes Plugin schreibt, muss diese durch die Klasse des Plugin ersetzen. Der Eintrag »kipiplugin_watermark« (Zeilen 6 und 7) steht für den Namen der zugehörigen ».desktop«-Datei.