Deklaration von Slots in D-Bus-Adaptern

Slots in D-Bus-Adaptern werden genau wie normale, öffentliche Slots deklariert, ihre Parameter müssen jedoch bestimmten Regeln entsprechen (weitere Informationen finden Sie unter „Das Qt D-Bus -Typensystem“ ). Slots, deren Parameter diesen Regeln nicht entsprechen oder die nicht öffentlich sind, sind über D-Bus nicht zugänglich.

Slots können einen Parameter vom Typ ` const QDBusMessage &` haben, der am Ende der Liste der Eingabeparameter stehen muss, noch vor etwaigen Ausgabeparametern. Dieser Parameter wird, sofern vorhanden, mit einer Kopie der aktuell verarbeiteten Nachricht initialisiert, wodurch der Aufgerufene Informationen über den Aufrufenden abrufen kann, beispielsweise dessen Verbindungsnamen.

Es gibt drei Arten von Slots:

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

Asynchrone Slots

Asynchrone Slots sind solche, 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 bereits ihre Arbeit wieder aufgenommen, wenn die erste Zeile des Slots ausgeführt wird.

Slots dürfen sich jedoch nicht auf dieses Verhalten verlassen. Probleme bei der Ablaufplanung und der Nachrichtenverteilung könnten die Reihenfolge ändern, in der der Slot ausgeführt wird. Code, der eine Synchronisation mit dem Aufrufer beabsichtigt, sollte eine eigene Synchronisationsmethode bereitstellen.

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

Reine Eingabe-Slots

Nur-Eingabe-Slots sind normale Slots, die Parameter entgegennehmen, die als Wert oder als konstante Referenz übergeben werden. Im Gegensatz zu asynchronen Slots wartet der Aufrufer jedoch in der Regel auf den Abschluss des Aufgerufenen, bevor er den Betrieb fortsetzt. Daher sollten nicht-asynchrone Slots nicht blockieren oder in ihrer Dokumentation ausdrücklich angeben, dass sie dies möglicherweise tun.

Nur-Eingabe-Slots weisen in ihrer Signatur keine besondere Kennzeichnung auf, außer dass sie nur Parameter entgegennehmen, die als Wert oder als konstante Referenz übergeben werden. Optional können Slots einen „ QDBusMessage “-Parameter als letzten Parameter entgegennehmen, der zur Durchführung einer zusätzlichen Analyse der Methodenaufruf-Nachricht verwendet werden kann.

Eingabe- und Ausgabeslots

Ähnlich wie reine Eingabe-Slots sind Eingabe- und Ausgabe-Slots solche, bei denen der Aufrufer auf eine Antwort wartet. Im Gegensatz zu reinen Eingabe-Slots enthält diese Antwort jedoch Daten. Slots, die Daten ausgeben, dürfen nicht-konstante Referenzen enthalten und können ebenfalls einen Wert zurückgeben. Die Ausgabeparameter müssen jedoch alle am Ende der Argumentliste stehen und dürfen nicht mit Eingabeargumenten vermischt sein. Optional kann ein „ QDBusMessage “-Argument zwischen den Eingabe- und Ausgabeargumenten stehen.

Automatische Antworten

Methodenantworten werden von der „ Qt D-Bus “-Implementierung automatisch mit dem Inhalt der Ausgabeparameter (sofern vorhanden) generiert. Slots müssen sich nicht darum kümmern, korrekte „ QDBusMessage “-Objekte zu erstellen und diese über die Verbindung zu senden.

Die Möglichkeit dazu 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() auf den Parameter „ QDBusMessage “ anwendet und die Antwort mit QDBusConnection::send() versendet. Die Implementierung von „ Qt D-Bus “ generiert in diesem Fall keine eigene Antwort.

Verzögerte Antworten

Unter bestimmten Umständen kann der aufgerufene Slot die Anfrage möglicherweise nicht sofort verarbeiten. Dies ist häufig der Fall, wenn die Anfrage einen E/A- oder Netzwerkvorgang beinhaltet, der möglicherweise blockiert.

Ist dies der Fall, sollte der Slot die Kontrolle an die Hauptschleife der Anwendung zurückgeben, um ein Einfrieren der Benutzeroberfläche zu vermeiden, und den Vorgang später fortsetzen. Dazu sollte er den zusätzlichen Parameter „ QDBusMessage “ am Ende der Eingabeparameterliste nutzen und eine verzögerte Antwort anfordern.

Wir erreichen dies, indem wir einen Slot schreiben, der die Anfragedaten in einer persistenten Struktur speichert und dem Aufrufer mithilfe von ` QDBusMessage::setDelayedReply` (true) mitteilt, 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 zufriedenzustellen.

Wenn die Anfrage bearbeitet wurde und eine Antwort vorliegt, sollte diese mithilfe des erhaltenen „ QDBusMessage “-Objekts gesendet werden. In unserem Beispiel könnte der Antwortcode etwa wie folgt aussehen:

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 die Rückgabewerte des Slots von ` Qt D-Bus` ignoriert. Sie dienen lediglich dazu, 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 ` angefordert, indem `QDBusMessage::reply()` für die ursprüngliche Nachricht aufgerufen wird. Es liegt dann in der Verantwortung des aufgerufenen Codes, dem Aufrufer schließlich eine Antwort zu senden.