Development/Tutorials/Services/Traders (de)
Development/Tutorials/Services/Traders
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
Oft ist es notwendig bestimmte Typen von Diensten oder Dienste mit bestimmten Eigenschaften oder Zwecken zu finden. KDE bietet eine einfacher und dennoch mächtige Anfragesprache um diesen Zweck zu erfüllen. Das ist die KTrader Query Sprache.
Die zwei Arten von "Tradern"
KDE bietet zwei Klassen an die sich als "Trader" (Händler, sie handeln quasi mit Diensten. Im weiteren Verlauf nennen wir sie aber Trader) verhalten können. Ein Trader nimmt eine Anfrage entgeben und gibt eine Liste von Diensten zurück, die auf den Anforderungen dieser Anfrage genügen. Es gibt einen TRader für Plugins und weitere Add-ons: KServiceTypeTrader. Daneben gibt es noch einen weiteren Trader für MimeTypes KMimetypeTrader. Beide sind sich recht ähnlich: Sie benutzen die gleiche Syntax für Anfragen, offer a singleton pattern accessor, liefern KService::Ptrs als Ergebnis und weitere Gemeinsamkeiten. Während sich diese Anleitung primär auf KServiceTypeTrader konzentriert, ist vieles von dem Inhalt auch auf die MimeType Traders anwendbar.
Dienst Typen
KServiceTypeTrader is used to locate individual components such as application plugins, screensavers, and control panels that are registered with the system. The primary concept used here, is that of the "service type". Each set of services has a unique service type, which makes it very easy to locate the sort of component needed.
This means that, each kind of application plugin is uniquely namespaced within the set of all services. So, it is trivial to locate plugins for a given application, without having to worry about getting another application's plugin in the list.
Examples of service types include:
- KParts/ReadWritePart
- KTextEditor/Document
- ScreenSaver
- TerminalEmulator
- UserAgentStrings
- ThumbCreator
- KDevelop/Plugin
There is no limit to the number of service types that a given application may use or register. Of course, service types are not limited to plugins and may be used for any sort of data component.
Creating new service types is covered in the next tutorial of this series: Creating and Loading Plugins Using KService
Benutzung von KServiceTypeTrader
Auf den "service trader" wird immer über self() zugegriffen. Mit der Klasse KServiceTypeTrader können wir dann einen von drei Schritten ausführen:
- query:Anfrage einer Liste von Diensten die bestimmten (wenn überhaupt) Kriterien genügen, die der Benutzer vorgibt.
- defaultOffers: Fragt alle Dienste unsortiert ab.
- preferredService: Ermittelt den bevorzugten Dienst für einen bestimmten Typ.
Der Code dazu ist relativ einfach:
KService::List services;
KServiceTypeTrader* trader = KServiceTypeTrader::self();
services = trader->query("KParts/ReadWritePart");
foreach (KService::Ptr service, services) {
kDebug() << "read write part" << service->name();
}
services = trader->defaultOffers("ThumbCreator");
if (services.isEmpty()) {
kDebug() << "no services found for ThumbCreator!";
}
KService::Ptr service = trader->preferredService("KDevelop/Plugin");
if (!service) {
kDebug() << "no preferred service found for KDevelop/Plugin";
}
In jedem Fall wird ein oder mehrere Dienste zurückgegeben, mit dem oden denen man verschiedene Operationen wie lokalisieren, beschreiben und laden durchführen kann.
Die KTrader Query Sprache
Die obigen Beispiele sind recht simpel und für die Anforderung vieler Applikationen nicht detailiert genug. Zum Beispiel könnten wir nur eine Liste von Plugins für eine bestimmte Kategorie benötigen, die mit einem bestimmten Mimetype assoziiert ist oder einen bestimmten Namen haben. Hier kommt die Anfragesprache ins Spiel.
The query language itself is designed to be human readable and flexible. KServiceTypeTrader::query optionally takes a query, in addition to the service type, and uses that to provide more fine-grained searches. So, for example, we'll modify the earlier example in the following way:
KService::List services ;
KServiceTypeTrader* trader = KServiceTypeTrader::self();
QString constraint = "'text/plain' in MimeTypes and "
"('KOfficePart' in ServiceTypes or "
" 'oasis' ~ [X-KDE-ExtraNativeMimeTypes])";
services = trader->query("KParts/ReadWritePart", constraint);
foreach (KService::Ptr service, services) {
kDebug() << "read write part" << service->name();
}
This code will look for a KPart that is both capable of reading/writing plain text files and is also a KOffice component, or can simply read ODF document formats.
Errors in queries are reported via debug output to console at runtime.
Reihenfolge der Operatoren
Die Anfragezeichenkette wird von links nach rechts ausgewertet, ein Abschitt nach dem anderen. Abschnitte werden durch boolsche Operatoren (siehe unten) oder Klammern unterteilt.
Basistypen
Drei Basistypen werden von der KTrader Query Sprache unterstützt:
- strings: Zeichenketten, die einfachen Anführungsstrichen (') umschlossen sein müssen
- booleans: Boolsche Werte (TRUE oder FALSE)
- signed integers: vorzeichenbehaftete Ganzzahlen
- signed floating point numbers: vorzeichenbehaftete Gleitkommazahlen
Kennungen
Identifiers in a query string are mapped to entries listed in the service's .desktop file. For example, "Name" is the name of the service, "ServiceTypes" is a list of the service types it supports.
Identifiers may only contain alphanumeric characters and the '-' character. Identifiers that do not start with an alphabetical character or that contain non-alphanumeric characters must be enclosed in brackets, e.g. [X-KDE-Init].
There are also three special identifiers:
- DesktopEntryName stands for the filename of the service desktop entry without its extension. This can be useful to exclude some specific services.
- DesktopEntryPath stands for the relative or full path to the .desktop file, see KService::desktopEntryPath.
- Library: a synonym for [X-KDE-Library] in the .desktop file.
An identifier can be checked for existence with the exist operator, e.g. "exist [X-KDE-Library]". This is especially useful when checking for the value of an identifier with a default value. For example, if MyProp is a property with type boolean, one might write "not exist MyProp or MyProp" to match MyProp with a default of "true".
Vergleichsoperatoren
Die folgenden Vergleichoperatoren können benutzt werden, um Werte von allen unterstützten Daten miteinander zu vergleichen:
- ==: gleichheit
- !=: ungleichheit
- <: kleiner als
- <=: kleiner oder gleich
- >: größer als
- >=: größer oder gleich
Mathematische Operatoren
Folgende mathematische Operatoren können auf Zahlentypen angewandt werden
- +
- -
- *
- /
Boolsche Operatoren
Folgende boolsche Operatoren werden unterstützt:
- and: logisches und
- or: logisches oder
- not: logisches nicht
Operatoren für Zeichenketten
Die Operatoren, die auf Gleichheit von Zeichenketten prüfen, geben einen boolschen Wert zurück, der anzeigt, ob erfolgreich oder nicht.
Zeichenkettenvergleiche werden mit folgenden Operatoren erledigt:
- ==: Gleichheit, Groß- und Kleinschreibung wird beachtet
- =~: Gleichheit, Groß- und Kleinschreibung wird nicht beachtet
- !=: Ungleichheit, Groß- und Kleinschreibung wird beachtet
- !~: Ungleichheit, Groß- und Kleinschreibung wird nicht beachtet
Teilzeichenketten können in Zeichenketten durch folgende Operatoren gesucht werden:
- ~: enthält, z.B. "'Bar' ~ 'FooBarBaz'" ist wahr
- ~~: enthält und Groß und Kleinschreibung wird ignoriert, z.B. "'Bar' ~~ 'FoobarBaz'" ist wahr
Einige Eigenschaftem wie MimeTypes oder ServiceTypes sind Listen von Zeichenketten. Diese Listen können mit den folgenden zwei Operatoren durchsucht werden:
- in: Die Liste enthält die Zeichenkette, z.B. "'MyApp/Plugin' in ServiceTypes'"
- ~in: Die Liste enthält die Zeichenkette und Groß- und Kleinschreibung wird ignoriert.