Development/Tutorials/Services/Introduction (de)

Development/Tutorials/Services/Introduction

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

Whenever your application needs to launch another desktop application, find available applications, load plugins or find application add-ons it's as simple as a few lines of code to do so and the code is quite similar regardless of what you are looking for.

Since most of the details involved in looking up services are hidden away from your application, if things change either due to time and new standards or platform specific features your code will continue to work. For instance, when KDE implemented the freedesktop.org specification for describing application launcher menu structures, application code that had been functioning previous to this continued to function without any changes or even a recompile.

Best of all, the services system provides a flexible system under the hood for users and administrators to be able to customize, add new entries, remove existing items and even lock down access without putting any burden of complexity on application developers.

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 also provides ways to load services by name directly with the serviceBy* set of methods, of which the safest and most recommended is serviceByStorageId:

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

Note that it passed back a KService::Ptr rather than just a KService. A KService::Ptr looks, acts and behaves just like a regular pointer (KService*) but it is automatically memory managed. It is not necessary to manually delete KService::Ptrs, because they are reference counted.

A list of all services can be retrieved using the KService::allServices method. Of course, one often wants finer grained control over locating services, which is the role of the KServiceTypeTrader and is the topic of the next tutorial in this series.

At this point we now have access to all sorts of information on the service, which in this case is an application called konqueror. We can even launch the app using this service:

if (service.isApplication()) {

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

}

This would launch konqueror and cause it to open the KDE homepage.

Dienste registrieren

Services are represented on disk as individual .desktop files. This makes it easy to add, remove, and customize services on the system. The .desktop files are organized by their type of service. Applications, plugins, protocols, and mimetypes are each kept in their own directories. The location of these directories is documented in the KDE Filesystem Hierarchy page. Installation is usually automated through the build system, such as CMake in KDE4.

Services may also have one or more "service types" that are used to categorize and search for them. While applications and mimetypes don't utilize this, plugins and other services do. These service types are registered by placing a .desktop file describing the service type in the correct location in the filesystem, usually share/kde4/servicetypes. See the KDE Filesystem Hierarchy page for more information.

The content and form of these .desktop files is covered in detail in the Creating and Loading Plugins Using KService tutorial.

SyCoCa: Der System Konfigurations Cache

While the .desktop (file) method is very handy for users (and adding new entries), performance could be an issue because it is common to have thousands of these files describing various mimetypes, applications, plugins, screensavers, etc. Thus, the entries are put into a binary cache which is accessed via shared memory by all applications. The cache is known as the System Configuration Cache, or SyCoCa for short. Loading and locating KServices is done via this cache, transparently to the application.

Whenever a new .desktop file is added, removed or altered, the cache is automatically updated by the kbuildsycoca application. You can force an update of the cache by running kbuildsycoca manually, though usually it is launched by kded automatically when needed. A full rebuild of the cache (versus a simple update) can be triggered by passing --noincremental to kbuildsycoca.

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.