Deklaration von Slots in D-Bus-Adaptern

Slots in D-Bus-Adaptern werden genau wie normale, öffentliche Slots deklariert, aber ihre Parameter müssen bestimmten Regeln folgen (siehe Das Qt D-Bus Typsystem für weitere Informationen). Slots, deren Parameter diesen Regeln nicht folgen oder die nicht öffentlich sind, sind nicht über D-Bus zugänglich.

Slots können einen Parameter des Typs const QDBusMessage & haben, der am Ende der Eingabeparameterliste vor den Ausgabeparametern stehen muss. Dieser Parameter wird, falls vorhanden, mit einer Kopie der aktuell verarbeiteten Nachricht initialisiert, die es dem Aufrufer ermöglicht, Informationen über den Aufrufer zu erhalten, wie z. B. seinen Verbindungsnamen.

Es gibt drei Arten von Slots:

1. Asynchron
2. Nur Eingabe
3. Eingabe und Ausgabe

Asynchrone Slots

Asynchrone Slots sind Slots, die normalerweise keine Antwort an den Aufrufer zurückgeben. Aus diesem Grund können sie keine Ausgabeparameter annehmen. In den meisten Fällen hat die aufrufende Funktion zu dem Zeitpunkt, an dem die erste Zeile des Slots ausgeführt wird, ihre Arbeit bereits wieder aufgenommen.

Slots dürfen sich jedoch nicht auf dieses Verhalten verlassen. Probleme mit der Zeitplanung und dem Nachrichtenversand können die Reihenfolge der Ausführung des Slots verändern. Code, der mit dem Aufrufer synchronisiert werden soll, sollte seine eigene Synchronisationsmethode bereitstellen.

Asynchrone Slots werden durch das Schlüsselwort Q_NOREPLY in der Methodensignatur vor dem Rückgabetyp void und dem Slotnamen gekennzeichnet. Der Slot quit() im D-Bus Complex Ping Pong Beispiel ist ein Beispiel dafür.

Eingabebeschränkte Slots

Input-Only-Slots sind normale Slots, die Parameter als Wert oder als konstante Referenz übergeben bekommen. Im Gegensatz zu asynchronen Slots wartet der Aufrufer jedoch in der Regel auf die Beendigung des Aufrufers, bevor er die Operation fortsetzt. Daher sollten nicht-asynchrone Slots nicht blockieren oder in ihrer Dokumentation ausdrücklich darauf hinweisen, dass sie blockieren können.

Nur-Eingabe-Slots haben keine besondere Kennzeichnung in ihrer Signatur, außer, dass sie nur Parameter annehmen, die als Wert oder als konstante Referenz übergeben werden. Optional können Slots einen QDBusMessage Parameter als letzten Parameter annehmen, der verwendet werden kann, um eine zusätzliche Analyse der Nachricht des Methodenaufrufs durchzuführen.

Eingabe- und Ausgabe-Slots

Wie reine Eingabe-Slots sind Eingabe- und Ausgabe-Slots solche, bei denen der Aufrufer auf eine Antwort wartet. Im Gegensatz zu reinen Eingabeschlitzen enthält diese Antwort jedoch Daten. Slots, die Daten ausgeben, können nicht konstante Referenzen enthalten und auch einen Wert zurückgeben. Die Ausgabeparameter müssen jedoch alle am Ende der Argumentliste stehen und dürfen keine Eingabeargumente dazwischen haben. Optional kann ein QDBusMessage Argument zwischen den Eingabe- und den Ausgabeargumenten stehen.

Automatische Antworten

Methodenantworten werden automatisch mit dem Inhalt der Ausgabeparameter (falls vorhanden) von der Qt D-Bus Implementierung erzeugt. Die Slots müssen sich nicht darum kümmern, geeignete QDBusMessage Objekte zu erstellen und über die Verbindung zu senden.

Die Möglichkeit, dies zu tun, bleibt jedoch bestehen. Sollte der Slot feststellen, dass er eine spezielle Antwort oder sogar einen Fehler senden muss, kann er dies tun, indem er QDBusMessage::createReply() oder QDBusMessage::createErrorReply() für den Parameter QDBusMessage verwendet und ihn mit QDBusConnection::send() sendet. Die Qt D-Bus Implementierung wird keine Antwort erzeugen, wenn der Slot dies tut.

Verspätete Antworten

Unter bestimmten Umständen kann der aufgerufene Slot die Anfrage nicht sofort bearbeiten. Dies ist häufig der Fall, wenn die Anfrage eine E/A- oder Netzwerkoperation beinhaltet, die blockiert werden kann.

In diesem Fall sollte der Slot die Kontrolle an die Hauptschleife der Anwendung zurückgeben, um ein Einfrieren der Benutzeroberfläche zu vermeiden, und den Prozess später wieder aufnehmen. Um dies zu erreichen, sollte er den zusätzlichen Parameter QDBusMessage am Ende der Eingabeparameterliste verwenden und eine verzögerte Antwort anfordern.

Wir tun dies, indem wir einen Slot schreiben, der die Anfragedaten in einer persistenten Struktur speichert und dem Aufrufer mit QDBusMessage::setDelayedReply(true) anzeigt, dass die Antwort später gesendet wird.

struct RequestData
{
    QString request;
    QString processedData;
    QDBusMessage reply;
};

QString processRequest(const QString &request, const QDBusMessage &message)
{
    RequestData *data = new RequestData;
    data->request = request;
    message.setDelayedReply(true);
    data->reply = message.createReply();

    appendRequest(data);
    return QString();
}

In diesem Fall ist der Rückgabewert unerheblich; wir geben einen beliebigen Wert zurück, um den Compiler zufrieden zu stellen.

Wenn die Anfrage verarbeitet wurde und eine Antwort verfügbar ist, sollte sie unter Verwendung des QDBusMessage -Objekts gesendet werden, das erhalten wurde. In unserem Beispiel könnte der Antwortcode wie folgt lauten:

void sendReply(RequestData *data)
{
    // data->processedData has been initialized with the request's reply
    QDBusMessage &reply = data->reply;

    // send the reply over D-Bus:
    reply << data->processedData;
    QDBusConnection::sessionBus().send(reply);

    // dispose of the transaction data
    delete data;
}

Wie im Beispiel zu sehen ist, werden bei einer verzögerten Antwort der oder die Rückgabewerte des Slots von Qt D-Bus ignoriert. Sie werden nur verwendet, um die Signatur des Slots zu bestimmen, wenn die Beschreibung des Adapters an entfernte Anwendungen übermittelt wird, oder für den Fall, dass der Code im Slot beschließt, keine verzögerte Antwort zu verwenden.

Die verzögerte Antwort selbst wird von Qt D-Bus durch den Aufruf von QDBusMessage::reply() auf die ursprüngliche Nachricht angefordert. Es liegt dann in der Verantwortung des aufgerufenen Codes, eine Antwort an den Aufrufer zu senden.