Development/Tutorials/Services/Introduction (de)

Development/Tutorials/Services/Introduction

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 | Українська | 简体中文 | 繁體中文

Zusammenfassung

Dienste (Services) stellen Applikationen, Plugins und andere Erweiterungen dar, die auf dem System verfügbar sind. Sie vereinfachen das Finden, Starten und Laden der Module, die sie repräsentieren ohne eine spezielle Erweiterung zum Zeitpunkt der Programmierung des Hauptprogrammes kennen zu müssen. Diese Anleitung beschäftigt sich damit, was das Dienste-System zur Verfügung stellt und wo die Informationen gespeichert werden.

Die Vorteile Dienste zu benutzen

Es gibt drei Hauptvorteile, Dienste zu benutzen:

• Es ist einfach
• Es ist zukunftssicher
• Es ist flexibel

Jedesmal wenn Ihre Applikation einen Dienst (andere Applikation, Plugin oder Add-on) benötigt, ist das starten und/oder laden so einfach, dass ein paar Zeilen Code ausreichen. Egal wonach gesucht wird, der Code sieht immer sehr ähnlich aus.

Da die meisten Details bei der Suche nach Diensten von Ihrer Applikation verborgen werden, wird Ihr Code auch dann noch funktionieren, wenn der darunterliegende Rahmen durch neue Standards oder plattformspezifische Eigenschaften verändert wird. Wenn KDE zum Beispiel die von freedesktop.org vorgeschlagenen Spezifikationen für die Beschreibung von Starmenüs implementiert, wird Ihr Code, der vorher funktioniert hat auch hinterher seinen Dienst tun ohne Änderungen oder ein Neuübersetzen.

Das beste ist, dass das Dienstesystem ein flexibles System ist, welches Benutzern und Administratoren ermöglicht Elemente zu ändern, hinzuzufügen, zu entfernen oder den Zugriff darauf einzuschränken ohne den Applikationsentwickler mit unnötiger Komplexität zu belasten.

Ein Blick auf die Klassen

Die Hauptklassen für Dienste, die von Applikationen am meisten benutzt werden sind in der Regel nur diese beiden:

• KService: Repräsentiert eine Applikation, ein Plugin oder eine Erweiterung
• KServiceTypeTrader: Erlaubt das Suchen nach verfügbaren Diensten durch eine einfache Suchanfragen Sprache. Diese Klasse und die Suchanfragen werden detailiert im folgenden Kapitel next tutorial besprochen.

Andere Klassen die verfügbar sind, jedoch wenig häufig von Applikationen benutzt werden sind unter anderem:

• KServiceOffer: Stellt Informationen über die Benutzervoreinstellungen zu einem bestimmten Service zur Verfügung und wird primär für mimitypes benutzt.
• KServiceType: Stellt Zugriff auf Informationen über einen bestimmten Typ von Diensten zur Verfügung.
• KServiceTypeProfile: Repräsentiert die Benutzervoreinstellungen zwischen verschiedenen Diensten des selben Typs. Wird intern von KServiceTypeTrader benutzt.

KService

Die KService Klasse bildet das Zentrum des Dienstsystems. Es spielt eine sowohl informative als auch funktionelle Rolle. KService stellt einen Zugriff auf die Details eines bestimmten Dienstes zur Verfügung, so zum Beispiel ob es eine Applikation ist, welchen Namen der Dienst hat, das assoziierte Icon (wenn es ein solches gibt) usw. Es kann aber auch benutzt werden, um Applikationen zu starten und Plugins von der Festplatte zu laden.

Ein KService Objekt kann auf drei Arten erzeugt werden:

• Erzeugung per Hand
• Anfordern über den Namen
• Eine Suchanfrage

Der erste Ansatz ist der direkteste und sieht ungefähr so aus: QString pathToDesktopFile = KStandardDirs::locate("apps",

                                                 "konqueror");

KService service(pathToDesktopFile);

KService bietet auch Möglichkeiten, einen Dienst direkt über den Namen zu laden und zwar über die serviceBy* Methoden. Die sicherste und am meisten empfohlene ist die serviceByStorageId:

KService::Ptr service = KService::serviceByStorageId("konqueror");

Beachten Sie, dass der Rückgabewerte KService::Ptr ist und nicht nur ein KService. Ein KService::Ptr sieht aus und verhält sich genau wie ein normaler Zeiger (KService*), wird jedoch automatisch im Speicher verwaltet. Daher ist es nicht notwendig einen KService::Ptr von Hand zu löschen, da sie einen eingebauten Referenzzähler haben.

Eine Liste aller Dienste kann mit der KService::allServices Methode geholt werden. Jedoch benötigt man eine detailiertere Kontrolle über die Dienste, das ist die Aufgabe der Klasse KServiceTypeTrader und das Thema des nächsten Kapitels dieser Serie.

An diesem Punkt haben wir jetzt Zugriff auf alle Arten von Informationen über einen bestimmten Service. In folgenden Beispiel soll konqueror aufgerufen werden. Um das zu bewerkstelligen können auch Dienste benutzt werden:

if (service.isApplication()) {

   KUrl::List urls;
   urls << "http://www.kde.org";
   KRun::run(service, urls, 0);

}

Dadurch wird Konqueror gestartet und die KDE Homepage geöffnet.

Dienste registrieren

Dienste werden auf der Festplatte als individuelle .desktop Dateien beschrieben. Das macht es einfach, Dienste hinzuzufügen, zu löschen oder anzupassen. Die .desktop Dateien werden vom jeweiligen Diensttyp organisiert. Applikationen, Plugins, Protokolle und Mimetypes werden jeweils in einem eigenen Verzeichnis aufbewahrt. Der Ort dieser Verzeichnisse wird in KDE Filesystem Hierarchie beschrieben. Die Installation wird in der Regel durch das Build-System automatisiert, zum Beispiel CMake in KDE4.

Diensten können auch ein oder mehr "Diensttypen" haben, die benutzt werden, um sie zu kategorisieren und nach ihnen zu suchen. Während Applikationen und Mimetypes dies nicht benötigen, benötigen Plugins und andere Dienste diese Funktion. Die Diensttypen werden bestimmt, indem man eine .desktop Datei an einer bestimmten Stelle im Verzeichnissystem anlegt, die den Diensttyp näher bestimmt. Dieses Verzeichnis ist in der Regel share/kde4/servicetypes. Näheres findet man im Kapitel KDE Filesystem Hierarchie.

Der Form und Inhalt dieser .desktop Dateien wird im Detail im Kapitel Erzeugen und Laden von Plugins über KService beschrieben.

SyCoCa: Der System Konfigurations Cache

Während die Methode mit .desktop-Dateien recht einfach für Benutzer und das hinzufügen neuer Einträge ist, kann die Effizienz ein Problem werden, da es nicht unüblich ist, mehrere tausend dieser Dateien (die verschiedene Mimetypes, Applikationen, Plugins, Bildschirmschoner, etc beschreiben) zu haben. Aus diesem Grund werden die Einträge in einen binären Cache geschrieben, der über shared memory von allen Applikationen benutzt werden kann. Dieser Cache nennt sich System Configuration Cache, oder kurz SyCoCa. Finden und Laden von KServices wird transparent für die eigene Applikation durch diesen Cache erledigt.

Jedesmal wenn eine neue .desktop Datei hinzugefügt, entfernt oder verändert wird, wird der Cache automatisch von der kbuildsycoca Applikation aktualisiert. Man kann eine Aktualisierung erzwischen, indem man kbuildsycoca per Hand aufruft, obwohl es normalerweise von kded aufgerufen wird, wenn es nötig ist. Ein vollständiges Neuerzeugen des Zwischenspeichers (und nicht nur ein einfachen auffrischen) kann dadurch erzwungen werden, dass man --noincremental an kbuildsycoca übergibt.

Nach Diensten suchen

Das nächste Kapitel ist Dienste über Trader queries finden. Wir werden sehen, wie man Dienste über die KTrader query language und die KServiceTypeTrader Klasse findet.