freesoftware, GSoC, Kde, Planet

KDE Telepathy in GSoC 2012

We had several good proposals related to KDE Telepathy for Google Summer of Code 2012, but unfortunately we only got 2 slots! But hey, we got 2 slots! That’s great! 😀 Thanks to Google for organising and sponsoring it.

The first accepted project is “Message Filtering Plugin System” by Lasath Fernando (shocklateboy92), the author of the chat plasmoid that will be released in KDE Telepathy 0.4. He will be mentored by David Edmundson and

“will create a completely asynchronous modular and extensible system that enriches messages before they’re displayed to the user. These includes embedding images and videos from links, Translating messages, (re)-formatting them nicely, reading out loud etc.”

The second project is “Enhancement to peer-to-peer DBus for Telepathy DBus Tubes” by Puneet Goyal. Puneet worked on the Payment Detection use-case of project Alkimia in Season of KDE 2011. I will be his mentor for this interesting project which aim is to make it even easier to use D-Bus Tubes from any KDE application:

“When an application connects to a peer to peer dbus tube, it must know what exactly to look for. Even When it registers for another object, the other side of the tube must know about it. So the ideas is to create a class that could ease the object to register and unregister on the DBus Tubes, and to provide you with an interface similar to the one as a DBus Server.”

We had to reject several good projects, because of the limited amount of slots, but if you are motivated to work on a project in KDE Telepathy you still have one chance[1]: Season of KDE (SoK)! SoK is similar to Google Summer of Code: you won’t be paid, but you will get a mentor, a very cool t-shirt and certificate! If you want to apply, you can have a look at KDE Telepathy ideas that we selected for GSoC but did not get a slot (“Telepathy setup for KDE multiplayer games” and “Collaborative editor“), check out some more ideas here or propose your own idea.


[1]Actually you have as many chance as you want to contribute even if you don’t want to take part to SoK! We have several junior jobs if you are (or want to become) a developer, and a few non-programming tasks that don’t require programming skill if you just want to help us!

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

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

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!

freesoftware, GSoC, Kde, Planet

GSoC update

Just a quick update about my GSoC project:

  • StreamTubes works both offering and accepting, and both on Tcp and Local sockets (code still needs some cleaning)
  • I’m waiting for Dario to add DBusTubes support in Telepathy-qt4. Then it shouldn’t take much time…
  • Sending and receiving files works, but I’m writing on a telepathy kioslave that will allow, for example, to send files using drag and drop or starting a copyjob.
  • I had some troubles with receiving file transfer due to telepathy-gabble 0.9, even the telepathy-qt4 example is not working, so I switchd back to 0.8
  • Today I quickly installed a local xmmp server (ejabberd) on my laptop. Now I have a local server and a remote server with several testing accounts on each, 2 different kde builds from trunk and a big mess on my hard disk, tons of code that need to be cleaned and a huge todo list… 😛
  • I hope to start working on plasma widget sharing as soon as I come back from Akademy…

Ah! I almost forgot…

I'm going to Akademy 2010
I'm going to Akademy 2010
freesoftware, GSoC, Kde, Planet

Hello Planet KDE && GSoC: Telepathy Tubes and File Transfer in KDE

Hello Planet KDE,
My name is Daniele (drdanz on irc), I’m a PhD student from Italy and this summer I’ll take part in Google Summer of Code with KDE.

The aim of my project “Telepathy Tubes and File Transfer in KDE” is to provide a bridge for Telepathy Tubes and for file transfer using Telepathy.
Then the new framework will be used in two different applications:

  • Plasma widgets sharing with contacts using StreamTubes
  • Collaboration in mathematical software using Cantor and Telepathy DBusTubes

(If you don’t know what are Telepathy and Telepathy Tubes you can find some informations here, here and here)

So… let’s start from the beginning

Phase 1: Telepathy tubes and file transfer KDE bridge

The first part of the project will be a “bridge” which makes it easy to access to Telepathy Tubes and File transfer Telepathy-qt4 functions using Nepomuk resources.

It will add classes and functions to offer and accept StreamTubes and D-Tubes and to send and receive files. It will also aim to get integration with knotify and a service menu to send files to contacts right clicking on a file from file manager.

Phase 2: Plasma widget sharing with contacts

Since KDE 4.4, Plasma allows to share widgets over a network. It is possible for widgets to be interacted with remotely and simultaneously by several people. A big limitation is that widget are shared/discoverd using avahi/zeroconf, and this means that they can be shared only on the same subnet.

StreamTubes will be used to allow the widget to be shared with contacts using instant messaging protocols. Widget sharing protocol is already defined, so there is no need to rewrite it, StreamTubes will allow to transport it over the network using telepathy and IM protocol.

Phase 3: Collaboration in Math Software using Cantor

Cantor already allows to share worksheets using Get Hot New Stuff, but collaborative editing of a worksheet would be really useful and a killer feature for promoting Cantor over other Math software.

This will add some features to cantor that will be enabled or disabled depending on the used backend:

  • Synchronization of entered commands: Entered command will be sent to all people working on the same worksheet, and will be executed simultaneously.
  • Collaborative editing of worksheet: Worksheet sections will be locked while someone else is editing that section.
  • Figures sending to contacts: In order to send your figures to someone, Math software usually takes some time (save the figure, open kopete, find the contact, right click, etc.); sending figures as png to a contact just right clicking on the figure could be really useful time-saver
  • Variables syncing (optional): commands could be execute on just one pc instead of running it on all of them, and then the results shared. (This part might be a bit tricky, because Cantor doesn’t offer any access to the variables at the moment, but there are plans to write a variable inspector, so this feature will be left as last and will be implemented only if an easy access to variables will be possible)

Looks like it will be a very funny summer!