staging.inyokaproject.org

qdbus zu benutzen ist schon toll... aber wie schaffe ich es pbuilder (auf den launchpad.net-Rechnern) zu sagen, dass unter Hardy libqt4-dbus installiert werden muss, damit qt-shutdown-p gebaut werden kann? - Unter Hardy ist libqt4-dbus in den backports und wenn ich in dem control-file unter Build-Depends libqt4-dbus anhänge, führt das zu diesem Output:

dpkg: dependency problems prevent configuration of pbuilder-satisfydepends-dummy:
 pbuilder-satisfydepends-dummy depends on debhelper (>= 5); however:
  Package debhelper is not installed.
 pbuilder-satisfydepends-dummy depends on libqt4-dev; however:
  Package libqt4-dev is not installed.
 pbuilder-satisfydepends-dummy depends on libqt4-dbus; however:
  Package libqt4-dbus is not installed.
dpkg: error processing pbuilder-satisfydepends-dummy (--install):
 dependency problems - leaving unconfigured
Errors were encountered while processing:
 pbuilder-satisfydepends-dummy
[...]
Current status: 0 broken [-1].
Aptitude couldn't satisfy the build dependencies
E: pbuilder-satisfydepends failed.
I: Copying back the cached apt archive contents
I: unmounting dev/pts filesystem
I: unmounting proc filesystem
I: cleaning the build env 
I: removing directory /var/cache/pbuilder/build//3949 and its subdirectories

Wer genaueres wissen will: Hier
pbuilder selbst anzupassen steht außer Frage, da der Paketbau über launchpad.net läuft. Vielleicht kann ich ja was an der debian/control oder der debian/rules anpassen, damit das klappt?

Gruß
Hakaishi

Problem gelöst:

Aus den IRC:
<maxb> hakaishi: PPAs will only resolve dependencies from the backports pocket if you configure them to do so. If that's the only problem with the package build, you can reconfigure your PPA and retry the build
<hakaishi> maxb: what do I need to configure? - And how?
<maxb> Go to your PPA's web page and click "Edit PPA Dependencies"

Weiß jemand wie man verhindert, dass ein Programm mehr als einmal gleichzeitig laufen kann? Und wie man verhindert, dass der PC während das Programm läuft in den Standby geht?

Gruß
Hakaishi

@hakaishi: Um zu verhindern, dass die Applikation mehrfach gestartet wird, musst Du irgendeine Art von IPC nutzen, um zu prüfen, ob das Programm bereits läuft. Bei einer Desktop-Anwendung wie der Deinen bietet sich DBus an: Du registrierst Deine Anwendung mit einem eindeutigen Namen auf dem Session-Bus, und prüfst vor dem Starten der Anwendung, ob Du zu diesem Namen verbinden kannst. Falls ja, läuft die Anwendung bereits, und Du brichst den Anwendungsstart ab. Falls nein, startest Du Deine Applikation.

Lunar schrieb:

@hakaishi: Um zu verhindern, dass die Applikation mehrfach gestartet wird, musst Du irgendeine Art von IPC nutzen, um zu prüfen, ob das Programm bereits läuft. Bei einer Desktop-Anwendung wie der Deinen bietet sich DBus an: Du registrierst Deine Anwendung mit einem eindeutigen Namen auf dem Session-Bus, und prüfst vor dem Starten der Anwendung, ob Du zu diesem Namen verbinden kannst. Falls ja, läuft die Anwendung bereits, und Du brichst den Anwendungsstart ab. Falls nein, startest Du Deine Applikation.

Es würde auch bool QApplication::isSessionRestored () const ausreichen... aber ich bekomme "src/main.cpp:18: error: ‘isSessionRestored’ was not declared in this scope" *grrr*
Okay, das mal beiseite. Wie registriere ich meine Anwendung auf dem Session-Bus? - Mit bool registerService ( const QString & serviceName ), oder wie???

@hakaishi: Ausprobieren ☺

Das hier sollte ja eigentlich funktionieren, aber das Programm wird sofort nach dem Start wieder beendet:

1
2
3
4

[...]
bool reg = QDBusConnection::sessionBus().registerService("qt-shutdown-p");
if(!reg)
  app.quit();

Und das hier zeigt das gleiche Verhalten:

1
2
3

[...]
if(QDBusConnection::sessionBus().registerService("qt-shutdown-p"))
  return app.exec();

Kann mir da jemand weiterhelfen?

Die Registrierung schlägt immer fehl, weil "qt-shutdown-p" kein gültiger Name für einen DBus-Dienst ist. Dokumentiert ist das auf der Seite Introduction to D-Bus, Abschnitt „Service Names“.

Nichts gegen Fragen, aber die Dokumentation musst Du schon auch lesen. Nichts für ungut …

Lunar schrieb:

Die Registrierung schlägt immer fehl, weil "qt-shutdown-p" kein gültiger Name für einen DBus-Dienst ist. Dokumentiert ist das auf der Seite Introduction to D-Bus, Abschnitt „Service Names“.

Nichts gegen Fragen, aber die Dokumentation musst Du schon auch lesen. Nichts für ungut …

Ich wusste nicht, dass es dafür eine Doku gibt... (es wäre hilfreich gewesen, wenn bei dieser Funktion noch mal darauf hingewiesen würde). Folgendes habe ich jetzt gemacht:
In main.cpp:

1
2
3

[...]
if(QDBusConnection::sessionBus().registerService("org.qt_shutdown_p"))
  return app.exec();

In gui.cpp:

1
2
3
4
5
6
7

[...]
void Gui::closeEvent(QCloseEvent* window_close){
    saveWindowSize();
    QDBusConnection::sessionBus().unregisterService("org.qt_shutdown_p");
    QWidget::closeEvent(window_close);
}
[...]

Jetzt müsste ich nur noch wissen, wie man mittels qdbus den Standby verhindern bzw. unterdrücken kann, solange das Programm läuft... - Ich habe da vor ein paar Tagen was gelesen, aber ich finde es nicht mehr -.-

Gruß
Hakaishi

Naja, es liegt nicht allzu fern, nach einer DBus-Einführung zu suchen, wenn man sich das erste Mal damit beschäftigt. Wenn man auf der Overviews-Seite nach „D-Bus“ sucht, findet man diese Einführung auch. Außerdem gibt es ja noch die offizielle D-Bus-Dokumentation.

Du musst den Dienst meines Wissens nach nicht explizit de-registrieren. Das sollte beim Beenden der Anwendung vielmehr automatisch geschehen.

Im Bezug auf das Verhindern des Standby-Modus kann ich Dir nicht weiterhelfen.

Ich denke, dass ich da was gefunden habe, weiß aber noch nicht wie ich das umsetzen soll:
http://www.marcuscom.com/hal-spec/hal-spec.html#locking

Gruß
Hakaishi

Du musst eben auf dem PowerManagement-Device die entsprechenden Lock-Methoden aufrufen. Die Methoden sind in der Spec ebenfalls beschrieben.

Lunar schrieb:

Du musst eben auf dem PowerManagement-Device die entsprechenden Lock-Methoden aufrufen. Die Methoden sind in der Spec ebenfalls beschrieben.

Ich habe folgendes versucht:

dbus-send --print-reply --system --dest=org.freedesktop.Hal /org/freedesktop/Hal/devices/computer org.freedesktop.Hal.Device.SystemPowerManagement.Suspend.AcquireInterfaceLock boolean:true

Mit folgendem Ergebnis:

Error org.freedesktop.DBus.Error.AccessDenied: Rejected send message, 1 matched rules; type="method_call", sender=":1.66" (uid=1000 pid=2479 comm="dbus-send) interface="org.freedesktop.Hal.Device.SystemPowerManagement.Suspend" member="AcquireInterfaceLock" error name="(unset)" requested_reply=0 destination="org.freedesktop.Hal" (uid=0 pid=922 comm="hald))

Mache ich was falsch, oder habe ich wirklich keine Zugriffsrechte? - Kann man das irgendwie umgehen?

Gruß
Hakaishi

Probiere das aus einem Programm heraus, wenn Du einen Service-Namen registriert hast. DBus ermöglicht recht komplexe Zugriffsbeschränkungen, u.a. auch mit Identifizierung des „Absenders“ einer DBus-Nachricht. Bei Locks ist diese Identifizierung inhärent, da kein anderer Client auf ein gesperrtes Objekt zugreifen darf. Deswegen ist es zwingend erforderlich, den Dienst, der die Sperre belegt hat, zu identifizieren. Ich könnte mir vorstellen, dass DBus Locks für anonyme Verbindungen wie dbus-send deswegen verbietet.

Ich habe es endlich (selber) herausgefunden. Der Befehl in der Konsole/Terminal sieht wie folgt aus:

dbus-send --print-reply --system --dest=org.freedesktop.Hal /org/freedesktop/Hal/devices/computer org.freedesktop.Hal.Device.AcquireInterfaceLock string:org.freedesktop.Hal.Device.SystemPowerManagement.Suspend boolean:true 

Das war vielleicht eine Geburt!!!

So, jetzt weiß Ich allerdings nicht, wie ich das im Programm implementieren soll...
Wie hänge ich in doSomething.call(...) die zwei Parameter (string und boolean) an?

Gruß
Hakaishi