Development/Tutorials/Services/Introduction (de): Difference between revisions

Revision as of 14:29, 14 July 2012

Einführung

Anleitungsserie	Dienste
Voriges Kapitel	keine
Nächstes Kapitel	Dienste finden mit Trader Queries
Weiterführende Texte	freedesktop.org Desktop File (englisch) Specification freedesktop.org Menu (englisch) Specification freedesktop.org MimeType specification englisch
Navigation	Deutsche Startseite

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 erzwingen, 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.

@@ Line 1: / Line 1: @@
-{{Template:I18n/Language Navigation Bar|Development/Tutorials/Services/Introduction}}
+{{TutorialBrowser (de)|
+series=Dienste|
+name=Einführung|
+pre=keine|
+next=[[../Traders_(de)|Dienste finden mit Trader Queries]]|
+reading=[http://www.freedesktop.org/wiki/Specifications/desktop-entry-spec freedesktop.org Desktop File (englisch) Specification]<br>[http://www.freedesktop.org/wiki/Specifications/menu-spec freedesktop.org Menu (englisch) Specification]<br>[http://www.freedesktop.org/wiki/Specifications/shared-mime-info-spec freedesktop.org MimeType specification englisch]
+}}
 == Zusammenfassung ==
@@ Line 11: / Line 24: @@
 * 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.
+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.
-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.
+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.
-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.
+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 ==
@@ Line 36: / Line 49: @@
 *Eine Suchanfrage
 Der erste Ansatz ist der direkteste und sieht ungefähr so aus:
-<code cppqt>
+<syntaxhighlight lang="cpp-qt">
 QString pathToDesktopFile = KStandardDirs::locate("apps",
                                                    "konqueror");
 KService service(pathToDesktopFile);
-</code>
+</syntaxhighlight>
-KService also provides ways to load services by name directly with the <tt>serviceBy*</tt> set of methods, of which the safest and most recommended is <tt>serviceByStorageId</tt>:
+KService bietet auch Möglichkeiten, einen Dienst direkt über den Namen zu laden und zwar über die <tt>serviceBy*</tt> Methoden. Die sicherste und am meisten empfohlene ist die <tt>serviceByStorageId</tt>:
-<code cppqt>
+<syntaxhighlight lang="cpp-qt">
 KService::Ptr service = KService::serviceByStorageId("konqueror");
-</code>
+</syntaxhighlight>
-Note that it passed back a <tt>KService::Ptr</tt> rather than just a {{class|KService}}. A <tt>{{class|KService}}::Ptr</tt> looks, acts and behaves just like a regular pointer (<tt>{{class|KService}}*</tt>) but it is automatically memory managed. It is not necessary to manually delete <tt>KService::Ptr</tt>s, because they are reference counted.
+Beachten Sie, dass der Rückgabewerte <tt>KService::Ptr</tt> ist und nicht nur ein {{class|KService}}. Ein <tt>{{class|KService}}::Ptr</tt> sieht aus und verhält sich genau wie ein normaler Zeiger (<tt>{{class|KService}}*</tt>), wird jedoch automatisch im Speicher verwaltet. Daher ist es nicht notwendig einen <tt>KService::Ptr</tt> von Hand zu löschen, da sie einen eingebauten Referenzzähler haben.
-A list of all services can be retrieved using the <tt>{{class|KService}}::allServices</tt> method. Of course, one often wants finer grained control over locating services, which is the role of the {{class|KServiceTypeTrader}} and is the topic of the next tutorial in this series.
+Eine Liste aller Dienste kann mit der <tt>{{class|KService}}::allServices</tt> Methode geholt werden. Jedoch benötigt man eine detailiertere Kontrolle über die Dienste, das ist die Aufgabe der Klasse {{class|KServiceTypeTrader}} und das Thema des nächsten Kapitels dieser Serie.
-At this point we now have access to all sorts of information on the service, which in this case is an application called <tt>konqueror</tt>. We can even launch the app using this service:
+An diesem Punkt haben wir jetzt Zugriff auf alle Arten von Informationen über einen bestimmten Service. In folgenden Beispiel soll <tt>konqueror</tt> aufgerufen werden. Um das zu bewerkstelligen können auch Dienste benutzt werden:
-<code cppqt>
+<syntaxhighlight lang="cpp-qt">
 if (service.isApplication()) {
      KUrl::List urls;
@@ Line 60: / Line 73: @@
      KRun::run(service, urls, 0);
 }
-</code>
+</syntaxhighlight>
-This would launch <tt>konqueror</tt> and cause it to open the KDE homepage.
+Dadurch wird <tt>Konqueror</tt> gestartet und die KDE Homepage geöffnet.
 == Dienste registrieren ==
-Services are represented on disk as individual <tt>.desktop</tt> files. This makes it easy to add, remove, and customize services on the system. The <tt>.desktop</tt> 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 System Administration/KDE_Filesystem_Hierarchy|KDE Filesystem Hierarchy]] page. Installation is usually automated through the build system, such as CMake in KDE4.
+Dienste werden auf der Festplatte als individuelle <tt>.desktop</tt> Dateien beschrieben. Das macht es einfach, Dienste hinzuzufügen, zu löschen oder anzupassen. Die <tt>.desktop</tt> 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 System Administration/KDE_Filesystem_Hierarchy|KDE Filesystem Hierarchie]] beschrieben. Die Installation wird in der Regel durch das Build-System automatisiert, zum Beispiel 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 <tt>.desktop</tt> file describing the service type in the correct location in the filesystem, usually {{path|share/kde4/servicetypes}}. See the [[KDE System Administration/KDE_Filesystem_Hierarchy|KDE Filesystem Hierarchy]] page for more information.
+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 <tt>.desktop</tt> Datei an einer bestimmten Stelle im Verzeichnissystem anlegt, die den Diensttyp näher bestimmt. Dieses Verzeichnis ist in der Regel {{path|share/kde4/servicetypes}}. Näheres findet man im Kapitel [[KDE System Administration/KDE_Filesystem_Hierarchy|KDE Filesystem Hierarchie]].
-The content and form of these .desktop files is covered in detail in the [[../Plugins|Creating and Loading Plugins Using KService]] tutorial.
+Der Form und Inhalt dieser .desktop Dateien wird im Detail im Kapitel [[../Plugins (de)|Erzeugen und Laden von Plugins über KService]] beschrieben.
 == SyCoCa: Der System Konfigurations Cache ==
+Während die Methode mit <tt>.desktop</tt>-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 '''Sy'''stem '''Co'''nfiguration '''Ca'''che, oder kurz SyCoCa. Finden und Laden von {{class|KService}}s wird transparent für die eigene Applikation durch diesen Cache erledigt.
-While the <tt>.desktop</tt> (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 '''Sy'''stem '''Co'''nfiguration '''Ca'''che, or SyCoCa for short. Loading and locating {{class|KService}}s is done via this cache, transparently to the application.
+Jedesmal wenn eine neue <tt>.desktop</tt> Datei hinzugefügt, entfernt oder verändert wird, wird der Cache automatisch von der {{path|kbuildsycoca}} Applikation aktualisiert. Man kann eine Aktualisierung erzwingen, indem man {{path|kbuildsycoca}} per Hand aufruft, obwohl es normalerweise von {{path|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 <tt>--noincremental</tt> an {{path|kbuildsycoca}} übergibt.
-Whenever a new <tt>.desktop</tt> file is added, removed or altered, the cache is automatically updated by the {{path|kbuildsycoca}} application. You can force an update of the cache by running {{path|kbuildsycoca}} manually, though usually it is launched by {{path|kded}} automatically when needed. A full rebuild of the cache (versus a simple update) can be triggered by passing <tt>--noincremental</tt> to {{path|kbuildsycoca}}.
 == Nach Diensten suchen ==
-Das nächste Kapitel ist [[../Traders|Dienste über Trader queries finden]]. Wir werden sehen, wie man Dienste über die KTrader query language und die {{class|KServiceTypeTrader}} Klasse findet.
+Das nächste Kapitel ist [[../Traders (de)|Dienste über Trader queries finden]]. Wir werden sehen, wie man Dienste über die KTrader query language und die {{class|KServiceTypeTrader}} Klasse findet.