DBus Qt bindings

[Peter Hawkins]

Hi...
On Wed, 28 Jan 2004 02:35 pm, Zack Rusin wrote:
> On Tuesday 27 January 2004 22:19, Peter Hawkins wrote:
> > What now?
>
> 1) Don't be using private constructors.

I have to in this case. Remember I have no intention of directly using any 
classes that wrap the interface - all I'm interested in is being able to use 
the python bindings that already exist with a Qt event loop. It seems to me 
that the simplest way to do this is to come up with an equivalent of the 
relevant bit of the glib bindings, ie. a way of saying 'Here is a 
DBusConnection, please look after it and look after the event delivery, 
otherwise don't bother me'.

If you have a better suggestion, I'd love to hear it.

> 2) Pick your religion and pray I'll have enough time to start chasing it
> or someone else takes it.

Well, I'm hoping you or someone else who knows more about dbus can help. I 
have gone to the extent of completely rewriting my own version of the Qt 
bindings which supported just what I needed but it suffered from exactly the 
same problem (ie. no event delivery).

> 3) Provide me some actually useful info like whether the socket
> notifiers in the integrator are actually watching and firing events and
> have me fix it.

Well, yes they are, but something isn't working (maybe to do with the main 
dbus library, not the qt bindings).

I'm running
sudo ./dbus-qt-monitor --system sender=org.freedesktop.Hal
while starting up the Hal daemon, just as a source of events.

Normally, using dbus-monitor, I see this sort of thing:
peterh@warpcore:~/tmp/dbus$ sudo dbus-monitor 
--systemsender=org.freedesktop.Hal

signal interface=org.freedesktop.DBus; member=ServiceAcquired; 
sender=org.freedesktop.DBus
string::1.106
signal interface=org.freedesktop.Hal.Manager; member=DeviceAdded; 
sender=:1.107
string:/org/freedesktop/Hal/devices/pci_1039_630
signal interface=org.freedesktop.Hal.Manager; member=DeviceAdded; 
sender=:1.107
string:/org/freedesktop/Hal/devices/pci_1039_5513
... many more signals ....

When using dbus-qt-monitor (which is my copy of tools/dbus-monitor trivially 
adapted to use a QApplication instead of a GMainLoop, and to call 
dbus_connection_setup_with_qt_main() as described above instead of 
dbus_connection_setup_with_g_main()), I see the following:
Integrator::slotRead(7)
Connection::dispatchRead()
signal interface=org.freedesktop.DBus; member=ServiceAcquired; 
sender=org.freedesktop.DBus
string::1.104
Integrator::slotRead(7)
Connection::dispatchRead()
Integrator::slotRead(7)
Connection::dispatchRead()
Integrator::slotRead(7)
Connection::dispatchRead()
... endless repetition of the above two lines ....

Incidentally, normally you see a 'ServiceAcquired' signal as soon as you run 
dbus-monitor, whereas here it didn't appear until after the hal daemon 
startup, implying something isn't working with signal delivery.

By looking at an strace, it seems to me that the relevant data is received and 
read by the process, but it is not dispatch()ed in a timely manner.

Any ideas?

=)
Peter