Bouncing between progress and setbacks

I started to have a deeper look into D-BUS as I will require an IPC facility if I want to provide a Qt4 API of QDS and still access KDE services.

So after I installed the dbus-1.0 packages, it played a bit the included tools, starting a session bus and watching output with dbus-monitor.

Then I tried to build a small test application using the Qt3 bindings, but unfortunately the headers didn't include any API documentation (I later found out the docs are in the source files, go figure)

As the version that is currently in Debian SID is quite old, I fetched a checkout from's CVS but it only contained the same outdated version I had already installed.

Browsing through SVN led me to a work branch directory created by Will Stephenson where he seemed to have started to backport the Qt4 bindings.

Seeing that most files still contained the Qt3 includes I guessed that he has currently no time for that endeavor but I looked like a good idea.

So I quickly copied the contents of my dbus checkout's qt directory over to qt3/ and ...


.. after fighting with the build system for a couple of hours (until I incidentally discovered it was looking for a different automake version than the one I had installed) successfully managed to get the files to compile after putting most of the Qt4 related code into comment blocks and changing includes to their Qt3 equivalents.

All functionality necessary to do basic sendAndReply() calls was recovered quite easily, but after some initial progress I ultimately failed to directly invoke slots based on the parameters delivered in messages for incoming methods calls.

Well, considering that this requires including private Qt headers it might be a good thing I didn't succeed :)

Limiting the approach to well defined signatures for slots expected for signal and async reply handlers seems to work a lot better. At least for signals, haven't tested async replies yet.

For method calls I am currently test driving an interface (abstract class) based model.

So, I could be at the "progress end" of the bounce before I get my well deserved sleep in a couple of minutes, but no, I had to watch the CPU meter during the last test: my test application takes all available CPU time :(

It seems the socket notifier used to handle the "writing" watch for D-BUS fires continuously, even after all calls and their replies have been processed.

Have yet to figure out why. Hopefully that will be one of the progresses tomorrow.


Hi Krake

As you guessed, I am out of time for working on that branch, but I will commit what I have and maybe that will fill in some of your blanks regarding the private QUObject bits. I'm not sure who you are but I will try and look you up.

Will Stephenson

By Will Stephenson at Mon, 12/12/2005 - 12:17

Ah, great.

The callback design I use at the moment works though and doesn't require the callback handler to be a QObject.

I hope I can keep the QVariant portions, Qt3 QVariant is more limited but it could be sufficient for most use cases.

Anyway, I'll checkout your work once you have it committed.

'm not sure who you are but I will try and look you up

The one who did the Licq KIMIface implementation ;)

By krake at Mon, 12/12/2005 - 18:51

I posted some info on calling slots here a while back you can find it here:
It also shows an alternative to marker interfaces.

By Richard Moore at Mon, 12/12/2005 - 13:44

Actually I managed to perform slot and signal invocation in a test program, but somehow got segfaults when trying it in the bindings backport.

But of course that could have had different reasons as well :)

My short term goal is to make the Qt3 bindings usable for the most common situations and more emphasis on being the caller than the service, but I'll check later where I can get closer to the Qt4 bindings code.

By krake at Mon, 12/12/2005 - 19:00