KDE-Telepathy Sprint 2 – Day 1

KDE-Telepathy Sprint 2 is officially started!
Everyone is so excited that we came to Collabora office too early and we were locked out! So while waiting someone started hacking…

Hacking outside Collabora office

Hacking outside Collabora office

Someone else spent his time in other ways…

d_ed juggling bananas outside Collabora office

d_ed juggling bananas outside Collabora office

Today we covered several topics and a lot of decision were taken:

  • Nepomuk
  • Licensing
  • CMake
  • Git
  • Logo and missing icons
  • Libraries/git submodules
  • GStreamer and Farsight
  • Chat UI Plugins
  • Launch and dinner

And most important of all:

  • Releasing Tech Preview KDE-Telepathy 0.2

This release still won’t be including any Nepomuk integration and will be mostly for the hundred of bug fixes shipped after the 0.1 release + some new cool feature.
This is the plan:

  • 18 September: Feature freeze! That means that we will decide all the features and the components that will be decided at the sprint. We will start the 0.2 branch on all the repositories
  • 8 October: “Big” Freeze (Strings will be frozen, translators will be able to start the translation, etc)
  • 30 October: Release

If you want to know more about what is happening at the sprint you can find some more pictures of the sprint here (I will continue to update it) and you can Follow real time updates #kdetpsprint on twitter and status.net


P.S. A big hug to vHanda who wasn’t able to join us because of visa problems… That sucks!


EDIT: More pictures by mck182 here

KDE-Telepathy Sprint 2 – Day 0

KDE-Telepathy isn’t officially started yet, but most of the team is already here, in Collabora office in Cambridge.

We have a very long Agenda for the sprint, and more todos are now on the whiteboard therefore all the people already started hacking.

Almost everyone is already at work

Almost everyone is already at work

While waiting for other people we also played the analogical version of KHangMan, also known as Hangman, but nobody managed to figure out this one:

G_O_E? We couldn't figure this out

G_O_E? We couldn't figure this out

Looks like it will be a pretty interesting sprint! Stay tuned.

KDE Telepathy 0.1 released! Part 4 of 5 – File Transfer Handler

Sorry, no fancy UI for this component.

This is a small module (nonetheless quite painful to test) that just handles file transfer, nothing more and nothing less (even accepting/refusing file transfer is a task for the approver, therefore it is not handled by this module). You won’t usually see anything, except a kjob running in the notification area and some info messages. The handler will be started automatically when a new incoming/outgoing file transfer should be handled and will exit (if no other file transfer channels are received) a few seconds after finishing its job.

The cool thing is ANY program from your desktop can just request the file transfer! Telepathy Mission Control will assign the file transfer channel to the file transfer handler, that will take care about transferring the file to your contact.

To demonstrate that it works, here’s a screenshot!

Transfer Completed! (Yes, it works sometimes)

Transfer Completed! (Yes, it works sometimes)

Ok, I admit that the screenshot is ugly and useless 😀

It still has several issues, first of all at the moment it just works (sometimes) with gabble (Jabber/XMPP) and salut (local link), because the other connection managers don’t support the URI property, therefore the handler will receive the channel, but won’t know which file should be sent. David fixed this for butterfly (MSN) but the patch was not integrated upstream yet. Moreover, for some reason it doesn’t work every time, failure reports (but also success reports!) are very appreciated! (You can use the bug tracker to report a new bug, attach the information to an existing bug or ping me on #kde-telepathy). Please attach to your reports the log from the file transfer handler (you can see the log running on a shell “telepathy-kde-filetransfer-handler --debug --persist” before starting the file transfer) and possibly the accounts that you and your contact are using (not the whole uid but at least the server “@xxxx.xx” part).

Note: When file transfer fails you will probably have a job running in your notification area that is impossible to remove unless you logout or remove the notification area from your system tray and re-add it. That’s a known issue, I’m working on it. Sorry about that.


File transfer handler comes together with a dolphin plugin! You will be able to send files just by right clicking on the files from dolphin:

Dolphin Plugin

Dolphin Plugin

This will open a dialog where you will be able to choose the recipient.

Send File Dialog

Send File Dialog

Sorry, sending multiple files and multiple recipients are not supported (yet).


By the way… Yes, I’m going to at Desktop Summit in Berlin!

I'm going to Desktop Summit - Berlin 2012

QtDbus peer-to-peer support and other good news

I’ve been really busy, so I was unable to blog for a while… And I’m still really busy, so this is just a quick update about what happened in the last few days.

  • My merge request [1] was finally merged in Qt master [2] and finally QTBUG-186 [3] is resolved. It took more than one year to get it in (the first version was submitted on March 26th, 2010), but it was definitely worth.
    This means that since Qt 4.8, QDBusServer won’t be just stub and QDBusConnection will have two new methods QDBusConnection::connectToPeer and QDBusConnection::disconnectFromPeer. You will be able to connect two applications directly and use DBus protocol for communication using Qt API, but without using the DBus daemon. (The only limitation is that you won’t be able to have both server and client in the same process and use blocking calls)
    This also means that DBusTubes using Telepathy-Qt4 (and therefore in KDE [4, 5]) will be soon possible (KDE 4.8 maybe?)
  • I succesfully defended my PhD Thesis (“Design and Development of a Framework for Tool Integration and Collaboration in Neuroinformatics and Computer-Aided Neurosurgery”), I’ll release the source code I wrote as soon as I find some time to do it (I need to clean the source code, translate comments, remove swears and other tasks like that before a serious release 😉 ), then I’ll probably write some blog posts about it.
  • Last but not least I am now engaged. 😀

[1]Merge Request 2342 – QtDbus peer-to-peer support
[2]Qt commit 685df07ff7e357f6848c50cffa311641afdca307
[3]QTBUG-186
[4]GSoC Update: DBusTubes work!
[5]Hello Planet KDE && GSoC: Telepathy Tubes and File Transfer in KDE

Qdbusxml2cpp and QDBusAbstractAdaptor Limitations

Issue #1:

Object implementing two different interfaces, both having a method named "Bar"

<interface name="org.drdanz.foo">
  <method name="Bar">
</interface>
<interface name="org.drdanz.boo">
  <method name="Bar">
</interface>

The adaptor code generated by qdbusxml2cpp is something like

[...]

QString fooAdaptor::Bar() const
{
    // handle method call home.drdanz.foo.Bar
    parent()->Bar();
}

[...]

QString booAdaptor::Bar() const
{
    // handle method call home.drdanz.boo.Bar
    parent()->Bar();
}

[...]

This means that the called method is the same, therefore it is not possible to have two different behaviours of the methods.

I don’t think that there is a way to know which of the methods called the parent()->Bar(); method and implement a simple switch (the QObject::sender() works only if called in a slot activated by a signal and I’m not aware of any other method to do that.

Solutions:

  1. Modify the auto-generated adaptor classes or to call a different method. (boring)
  2. Do not use qdbusxml2cpp and write the adaptor classes by hand, or don’t use adaptors at all (even more boring)

Issue #2

Objects implementing the same interface

class Base : public QObject {
  virtual <interface org.drdanz.foo> = 0
}
class Derived1 : public Base {
  <interface org.drdanz.foo>
  <interface org.drdanz.foo.bar1>
  <interface org.drdanz.foo.bar2>
}
class Derived2 : public Base {
  <interface org.drdanz.foo>
  <interface org.drdanz.foo.bar1>
  <interface org.drdanz.foo.bar3>
}
class Derived3 : public Base {
  <interface org.drdanz.foo>
  <interface org.drdanz.foo.bar2>
  <interface org.drdanz.foo.bar3>
}

Implementation of org.drdanz.foo.bar1 should available to all the classes that implement that interface.

Adaptors for interfaces org.drdanz.foo.barX cannot be created using Base as the parent class because Base should have virtual methods for every possible barX

(Just to demonstrate that a similar architecture make sense and is legal in D-Bus, an existing example is the Connection object in Telepathy, that must always implement the interface org.freedesktop.Telepathy.Connection, but can implement any number of additional org.freedesktop.Telepathy.Connection.Interface.XXXX interface.)

It is impossible to create a class Bar1 and declare

class Base : public virtual QObject {
  virtual <interface org.drdanz.foo> = 0
}
class Bar1 : public virtual QObject {
  <interface org.drdanz.foo.bar1>
}
class Derived1 : public Base, public Bar1;

because both Base and Bar1 needs to be QObject to be a parent for the adaptor and multiple inheritance is not supported for QObjects:

Warning: Class Derived1 inherits from two QObject subclasses Base and Bar1. This is not supported!

Solutions:

  1. Write/modify adaptors by hand (boring)
  2. Auto generate adaptors for every derived class and implement the methods multiple times (redundant and stupid)

A better possible solution to both issues:

Allow auto generated adaptors to use the methods on a QObject (adaptee) that is not the parent.

This is what qdbusxml2cpp produces in Qt 4.7:

qdbusxml2cpp produced adaptors in Qt 4.7

qdbusxml2cpp produced adaptors in Qt 4.7

The Object that "owns" the adaptor is the same that implements the real methods.

This is in my opinion what should be produced by qdbusxml2cpp:

What qdbusxml2cpp should produce

What qdbusxml2cpp should produce

The object that is registered on D-Bus exports all the adaptors, but the implementation of the interface can be in a different object

This requires just a few changes in the class QDBusAbstractAdaptor:

  1. Add a public (or protected) method to retrieve the adaptee QObject* adaptee() const;
  2. Add a method to set the adaptee void setAdaptee(QObject *adaptee);
  3. Add a constructor QBBusAbstractAdaptor(QObject *adaptee, QObject *parent).
    This doesn’t mean that adaptee must not be the parent, it just means that it can be a different object.
    Therefore to be backwards compatible the QBBusAbstractAdaptor(QObject *parent) must be modified to setAdaptee(parent)

Then a few changes are required in qdbusxml2cpp, to produce adaptors that use methods of the adaptee class instead methods of parent class.

An even easier implementation requires just to implement the adaptee logic in classes generated by qdbusxml2cpp

It could be enough to modify only qdbusxml2cpp

It could be enough to modify only qdbusxml2cpp