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]https://blogs.fsfe.org/drdanz/?p=273
[4]https://blogs.fsfe.org/drdanz/?p=276
[5]https://blogs.fsfe.org/drdanz/?p=292
[6]https://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!
