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

More Telepathy StreamTubes in KDE

Offering a TCP StreamTube finally works as it is supposed to do! So, if you want to start a streamtube, you just have to create an OfferTcpStreamTubeJob using your favorite method offered by TelepathyBridge:

KJob* offerTcpStreamTube(const Nepomuk::PersonContact& contact,
                         const QVariantMap& parameters = QVariantMap());
KJob* offerTcpStreamTube(const Nepomuk::PersonContact& contact,
                         const QHostAddress& hostAddress,
                         quint16 port = 0,
                         const QVariantMap& parameters = QVariantMap());
KJob* offerTcpStreamTube(const Nepomuk::PersonContact& contact,
                         QTcpServer* server,
                         const QVariantMap& parameters = QVariantMap());
KJob* offerTcpStreamTube(const Nepomuk::Person& metacontact,
                         const QVariantMap& parameters = QVariantMap());
KJob* offerTcpStreamTube(const Nepomuk::Person& metacontact,
                         const QHostAddress& hostAddress,
                         quint16 port = 0,
                         const QVariantMap& parameters = QVariantMap());
KJob* offerTcpStreamTube(const Nepomuk::Person& metacontact,
                         QTcpServer* server,
                         const QVariantMap& parameters = QVariantMap());

…for example…

Nepomuk::PersonContact targetContact = ...;
server = new QTcpServer;
server->listen();
KJob* job = TelepathyBridge::instance()->offerTcpStreamTube(targetContact, server);

…then just start the job…

connect( job, SIGNAL(result(KJob*)), this, SLOT (handleResult(KJob*))); job->start();

…and you should be able to forget that you are using telepathy and you can control everything using your QTcpServer!

If you feel brave enough to test it, you can find the code on gitorious

And now time for some more beautiful screenshots (Yeah, they are not really useful, but I wanted to show something šŸ˜› )

More StreamTube Parameters

More StreamTube Parameters

KNotify and StreamTubes

KNotify and StreamTubes


EDIT: I really hate you, WordPress! Iā€™m sorry for escaped characters…

My first Telepathy StreamTube in KDE

Telepathy StreamTube in KDE

Telepathy StreamTube in KDE

Ok, maybe it doesn’t make sense at the moment, you’ll have to wait a few more weeks to get something useful…

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!