freesoftware, Kde, Planet

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.

freesoftware, Kde, Planet

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

Basso, freesoftware, Kde, Planet, Qt

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

freesoftware, Kde, Planet, Qt

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
freesoftware, Kde, Planet

Telepathy-KDE: Questions and Answers

If you are reading this post is probably because you have questions about “Telepathy-KDE”… I’m sorry, you won’t find the answers here, yet. But since you are here… We want you to contribute the Q&A with your questions! (yeah, I must admit this is cheating)

I just came home from the Telepathy-KDE Sprint and I’m reading blog posts and comments. What I just realized is that people still don’t understand exactly what is telepathy, why do we want it in kde, if it will just replace kopete, if it will die like decibel, if it will be maintained and by who, what is a tube, if it can do <insert your favorite cool feature here>.

I think that we really need to do an effort to clarify everything to both “users” and “developers”, because we believe that telepathy is REALLY cool and it’s a shame if we are not able to transmit our enthusiasm to you…

A good start could be a good Q&A page somewhere (probably the KDE wiki will be a good place). I don’t have much time in this period and I prefer spending time coding than trying to guess what people wants to know! So please, leave your questions here as comment and I’ll try to answer to all of them.
Just ask anything you want to know. Also help is very welcome, so if you know something but you think that people might ignore, or if you can answer to a previous question feel free to leave both questions and answers.

Also I think the Q&A should be split in sections by category of users, so when you leave a question tell me who you are (this will be really helpful in sorting the questions):

  • a “basic user” (what the hell is telepathy, I just want to chat with my friends with a nice interface)
  • an “advanced user” (you will be using basic application like chat, file transfer, but want also advanced features)
  • a “developer” (you want to use instant messaging features in your application)
  • a “contributor” (you contribute or you want to help us developing telepathy integration in kde and plasma)
  • an “empathy user” or a “gnome user” (you already use empathy you want to know some details in what Telepathy-KDE is different from empathy and why our instant messaging application won’t have a cool name)
  • “someone else” (please specify)

Thank you!

freesoftware, GSoC, Kde, Planet

GSoC Project Summary: Telepathy Tubes and File Transfer in KDE

First of all an important note: KTelepathy is still in active development and there is still a huge amount of tasks to finish before the first real “preview release” [1] (any help is welcome). A telepathy sprint [2] is planned for september, so we’ll probably see a lot of progress soon!
The classes I wrote for GSoC are still pending for testing, review, and subject to sudden changes, that’s why I focussed on the library itself leaving the applications for later.

I started the GSoC writing a few jobs for SteamTubes, DBusTubes and file transfer channels:

  • Jobs to start a channel: The channel is started and handled in the same job and some result (if needed) is returned, for example a dbus connection for a dbus-tube. This is not exactly the best thing to do, because the channel should be requested to the channel dispatcher, and handled by the preferred handler.
  • Jobs to accept a channel: The incoming channel is handled and some result (if needed) is returned, exactly like the start channel. That means that a lot of code is redundant and duplicated.

So after writing a few applications of those jobs (file transfer in Cantor[3], Konqueror[4], and KSnapshot[5]) we decided to do a step backwards and to write some more jobs:

  • Jobs to request a channel: Request a channel to the channel dispatcher. The channel is not handled by the job itself, but must be handled by the default (or preferred) handler.
  • Jobs to handle a channel: This is mostly the same thing as the accept channel jobs, with the main difference that it is not limited to incoming jobs, but can also handle outgoing channels.

All those jobs use Nepomuk resources representing the “contact”. I wrote a couple of abstract classes that do most of the job so, and that are quite easy to subclass to handle new types of channels. I also wrote a job to start a “text chat” and integrated it into “telepathy-contactlist“, so it is now possible to start a chat that is handled by empathy or by “telepathy-chat-handler“.

About the QtDBus peer-to-peer connection patch, required for DBusTubes, I updated the merge request, adding unit tests as requested and fixing a few issues, but I’m still waiting for reviews. I really hope to get it reviewed and merged before Qt 4.8 feature freeze, but it’s not up to me now.

At aKademy, we fixed TelepathyQt4 DBusTube branch, so it really works now and we also wrote a cool “KWhiteboard[6] application to share a canvas over a DBusTube. It’s not really beautiful and yet, but it works!

I also started using DBusTubes in Cantor, but there is nothing really shared on the dbus tube yet, I’m writing some sort of “shared worksheet manager” class so that you can manage more than one worksheet on the same tube and that could be useful also for other applications.

Unluckily I wasn’t able to do any work on Plasma widget sharing. The protocol used now is not that simple as I thought, so getting widget shared over telepathy is not possible just using a StreamTube as planned and will take a lot more time than I expected when I proposed the project, and it wasn’t probably worth to work on it yet, as the library is quite unstable. Anyway this is still in my todo list!

Ok, that’s not all what I did during this summer, but this is the most important part of it. You can find some beautiful screenshots im my previous blog posts[3][4][5][6]

[1]https://bugs.kde.org/showdependencytree.cgi?id=232378&hide_resolved=1
[2]http://community.kde.org/Telepathy/Events/TelepathySprint1
[3]http://blogs.fsfe.org/drdanz/?p=273
[4]http://blogs.fsfe.org/drdanz/?p=276
[5]http://blogs.fsfe.org/drdanz/?p=292
[6]http://blogs.fsfe.org/drdanz/?p=260

P.S. Many thanks to Google, to my mentor George, to all #kde-telepathy people! It was definitely a very funny summer!

freesoftware, GSoC, Kde, Planet

Telepathy File Transfer in Konqueror

I wanted to write a Service Menu to send files from Dolphin, but I needed a dynamically loaded menu with the names of my contacts and this is not possible using Service Menu.

So I wrote a konqueror popup menu plugin (KonqPopupMenuPlugin).

It doesn’t work in dolphin though, because the plugin isn’t loaded.
Anyone knows if there is a way to get konqueror plugins loaded in dolphin or if there is a better way to do this?

Anyway, there it is!

"Send to..." menu in Konqueror