Written by Hello all KDE Fans,
As my project is concentrated on dbus tubes, I had to develop an application which implemented the dbus tubes. KWhiteboard was the perfect application for that. So I removed all the extra features that were not needed and I was left with a simple application for testing purposes.
My next task was to implement the org.freedesktop.DBus.Peer interface. I had to implement the Ping method and the GetMachineId method in it. At first, I took my time understanding the concepts of interfaces and adaptors. At the very first place, it did not take much time to implement the methods using the session bus, as in Ping method I just had to write a kDebug output and in retrieving the machine ID I used the QDBusConnection::localMachineId () method. Initially, it was working at its best. But as soon as I started testing it with the DBus Tubes by connecting it with a telepathy service, it gave me a lot of problems, the most significant one being explained later in the text. Now, Daniele even found out that the Peer interface was already implemented in QT and was not shown in the Introspect because Daniele’s patch was yet to be released in another QT 4.8.X may be.
One main problem that I faced was the QDBusInterface using blocking DBus calls in constructor. In this case Daniele suggested me to split my program into two halves where one of them would be registered for handling outgoing dbus tubes and the other for incoming dbus tubes.Machine will know by itself about the tube to be handled by respective half and will pass the channels with the right properties. At first it seems pretty easy when you/to work on the interfaces with the session bus, but it creates a lot of problem when it comes to the peer-to-peer DBus. After both, the applications were working successfully on the same machine,thanks to Daniele, I finally got back implementing the interface and didnt took much time as it was already implemented in the QT.
Then it was time to implement the org.freedesktop.DBus.ObjectManager Interface. First job was to send a signal to the other machine that was connected with the DBus Connection; if a new object was registered, some properties are changed and a new interface is added or removed. To send a signal, I couldn’t just write “emit interfaceAdded();”. For this I needed an adaptor that implements the interface on the DBus, but you cannot know when an object is registered, unless it is directly implemented in QT. Therefore some methods, that the applications will use when they register one object on DBus, were needed to tell the interface to emit the signals.
On the other side, an interface (QDBusAbstractInterface) was needed to listen to the signals and to call the methods.I will be explaining the whole process in a new post with much better explanation.
Now as I have completed all this, I have the KWhiteboard ready to test it. As Daniele suggested, I will try to make a tabbed KWhiteboard where when one side opens a new tab, a new object will get registered on the dbus.The adaptor will emit the signal, the proxy will receive it and the program that will be listening to that signal, will open a new tab on the otherside as well.
I have just started writing blog. Any type of suggestions or comments are welcome.
Regards,
Puneet
