freesoftware, GSoC, Kde, Planet

GSoC Update: DBusTubes work!

“D-Bus Tubes allow you to share a private D-Bus bus between two or more clients, proxied over Telepathy.” Basically this means that your client can create a dbus object and share its methods and signals with a client run by your contact (you can find more information here).

Here at Akademy in Tampere we fixed telepathy-qt4 and now Telepathy DBusTubes can be used in KDE!
You need to patch qt and you need to patch telepathy-qt4, but they do work!

We also set up a small demo application called KWhiteBoard, that is a shared white-board that allows you to draw very beautiful black and white drawings with your favorite remote friend. Well, the functionalities are quite limited at the moment, but it will get more soon!

KWhiteBoard "hello world"

If you want to try KWhiteBoard or just DBusTubes in your application you need to rebuild patched Qt and telepathy-qt4, but if you ping me on #telepathy-kde, (or if you are in tampere, I’ll be here until sunday morning) I’ll be happy to help you setting up everything!

4 thoughts on “GSoC Update: DBusTubes work!

  1. What I’m wondering is : how do we open a tube with someone ?
    I wonder if you may be able to open tubes via any protocol supported by Telepathy ? Because that would be awesome =) !
    And so the Telepathy / Tubes stuff may be implemented on any application and allow KDE users using XMPP for instance to share files or do some collaboration work via this GSoC ?

    1. Opening a dbus tube using telepathy-qt4 is just like opening a text channel or starting a file transfer…
      In KDE you will have the option to open a dbustube just starting a KJob, it will be quite similar to streamtubes (see but you will have a QDBusConnection instead of a server, and you will be able to register objects on that connection.

      At the moment I think that the only connection manager that supports dbustubes is gabble, but in the future I think that other connection managers will follow… And yes, that would be really awesome!

      And yes, my GSoC will allow any KDE application to add collaboration features and file transfer capabilities just by adding a few lines of code (although you can already do that using telepathy-qt4 directly) and then give some example (in cantor and in plasma) about how to do that!

  2. How easy would it be to have a contact manager kioslave instead of a full-blown application to view contacts ala netmeeting first few releases from microsoft? Adding servicemenus which can be easily scripted such as krfb, kopete send message, open chat with, send file to… etc. seems like the way forward. Applications can simply add servicemenus (and possibly register with connection-manager for incoming requests) when their applications are ready for such functionality.

    As an application developer, the only piece I can see waiting on is a contact kioslave in order to make connections to begin with. This might save a ton of code in Kopete for dealing with contact list, and open up wider possibilities in the future.

    contact:// metacontact (expandable tree) name1 account1 (and when expanded)name1 account2 which drag and dropped on primary account which of course has full name and vcard info takes precedence in database.

    How can KAddressBook end up with service-menu actions?

    Fields can be parsed from different protocol accounts and end up filling in vcards in storage (nepomuk / akonadi).

Comments are closed.