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

    From KDE TechBase
    (Navigationstemplate eingefügt)
    No edit summary
    (4 intermediate revisions by 3 users not shown)
    Line 1: Line 1:
    {{Template:I18n/Language Navigation Bar|Development/Tutorials/Services/Introduction}}


    {{TutorialBrowser(de)|
     
    {{TutorialBrowser (de)|


    series=Dienste|
    series=Dienste|
    Line 49: Line 49:
    *Eine Suchanfrage
    *Eine Suchanfrage
    Der erste Ansatz ist der direkteste und sieht ungefähr so aus:
    Der erste Ansatz ist der direkteste und sieht ungefähr so aus:
    <code cppqt>
    <syntaxhighlight lang="cpp-qt">
    QString pathToDesktopFile = KStandardDirs::locate("apps",
    QString pathToDesktopFile = KStandardDirs::locate("apps",
                                                       "konqueror");
                                                       "konqueror");
    KService service(pathToDesktopFile);
    KService service(pathToDesktopFile);
    </code>
    </syntaxhighlight>


    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>:
    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");
    KService::Ptr service = KService::serviceByStorageId("konqueror");
    </code>
    </syntaxhighlight>


    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.  
    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.  
    Line 67: Line 67:
    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:
    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()) {
    if (service.isApplication()) {
         KUrl::List urls;
         KUrl::List urls;
    Line 73: Line 73:
         KRun::run(service, urls, 0);
         KRun::run(service, urls, 0);
    }
    }
    </code>
    </syntaxhighlight>


    Dadurch wird <tt>Konqueror</tt> gestartet und die KDE Homepage geöffnet.
    Dadurch wird <tt>Konqueror</tt> gestartet und die KDE Homepage geöffnet.
    Line 88: Line 88:
    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.  
    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.  


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


    == Nach Diensten suchen ==
    == Nach Diensten suchen ==
    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.
    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.

    Revision as of 14:29, 14 July 2012


    Einführung

    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.