KDE Telepathy Bug Reports Count (Open bugs only)

The graph shows clearly that the number of bugs reports affecting KDE Telepathy is increasing.
Quite unlikely this is related to the quality of the software, but to the numbers of KDE-Telepathy users.

Editing the query a little bit I came to this graph, definitely more interesting (Source):

KDE Telepathy Bug Reports Count (All bugs)

The trend is in my opinion really impressive, and shows clearly the amazing job that has been done on KDE Telepathy since February 2011.

Bugs have been closed at a very constant rate, new features added, new versions released (0.5.1 was released about 20 days ago), and translators are doing a great job, with the result that now KDE Telepathy is packaged for most of the major GNU/Linux Distributions and at least 2 of them use it as default instant messaging framework for the KDE Desktop.

This implies new users, but obviously comes with a lot of new bug reports and new features requests.

That’s why we need you! Of course we need new developers to help us fixing bugs, we have junior-jobs if you are starting programming and want to learn, and we are very happy to help you!
But if you are not a coder, and you want to help us join us on #kde-telepathy on freenode, we have a lot of tasks for you anyway!

• Report new bugs, try to reproduce and confirm the existing ones, find out the duplicates, locate related bug on upstream and downstream bugtrackers
• Update the wiki, write the documentation for the applications
• Test Adium chat themes, help us fixing the broken ones
• Translate the languages not yet translated
• Reply to users questions on the forum and mailing lists

Concluding: We are awesome, want to be awesome too? Join us

Formatting Plugin

First of all, I fixed the formatting plugin. This allow you to format plain text, like Thunderbird Structured Text:

• *this is bold*
• _this is underlined_ (and not italics!)
• /this is italics/
• -this is strikethrough-

The plugin was disabled in 0.5 because it was broken (the regular expression detecting the tags to replace was not detecting correctly).
Beside fixing it, I modified it to avoid changing the text by removing the tags (i.e. ‘*’ or ‘/’). In this way, even though it might format some parts that user is probably not expecting to see formatted (for example some /*C comments*/), copy and paste will still work.
Moreover, I made it so that it will be very easy to add a configuration dialog to change its behaviour, so if you _really want this to be italics_, you will probably be able to configure it according to your needs in the future.

This plugin will be enabled by default in 0.6.

Syntax Highlighting Plugin

We often think about the final users, but sometimes we have to think about the developers
So I wrote a syntax highlighting plugin using jquery-snippet

A few screenshots are better than thousand words, so…

Meanwhile David had another cool idea for the syntax highlighting plugin: include a kate part into the qtwebkit view (You can find some details about how he did that here). This is his result:

Both approaches work great, my approach is more integrated in the chat, but David’s approach is also quite interesting. We don’t know yet whether release just one of them or both… Opinions?

Anyway, in order not to try to highlight all the messages, at the moment code must be included in a block like [code lang='cpp']...[/code]. This can be a bit annoying. Moreover copying and pasting code in the chat-ui is boring. Something like pastebinit would be really useful. That’s why I started writing…

ktp-paste-contact

This a very simple tool but it is something I’m really proud of, and that shows the potential of Telepathy…
It is a simple command line tool that reads from stdin and sends everything as a single message to a telepathy contact.
it takes as parameters, the account to use, the contact to send it to, and an optional parameter --format <language>.
If this parameter is specified, then the message is automatically included in a [code lang='cpp']...[/code] block using the syntax specified.

A few ideas for using it…

• git show | ktp-paste-contact --format diff --account <account> --contact <contact>
• cat file.cpp | ktp-paste-contact --format cpp --account <account> --contact <contact>
• echo "Hey dude, I'm so geek that I'm texting you from the command line" | ktp-paste-contact --account <account> --contact <contact>

You can find the code for the code-highlighting plugin in my clone repository for ktp-text-ui (kde:clones/ktp-text-ui/ddomenichelli/ktp-text-ui branch plugin-code) and for ktp-paste-contact on my brand new scratch repository (kde:scratch/ddomenichelli/ktp-paste-contact.git)

Enjoy it!

while true; do echo "MUAHAHAHAHAHA" | ktp-paste-contact --account <account> --contact <contact>; sleep 5; done

I'm going to Akademy 2012

As you can imagine from the picture above, I’m going to Akademy 2012 in Tallinn, Estonia! Thanks a lot to KDE e.V. for sponsoring me.

This year at the conference there will be a lot of interesting talks but unfortunately none of them about KDE-Telepathy.

Instead we will host 2 BoF sessions:

• KDE Telepathy meet’n'hack: Wednesday 13:00 Room 319
• KDE Telepathy “Tubes” Workshop: Thursday 14:00 Room 319

Moreover most of us will probably attend at the Web Accounts BoF:

• Web Accounts: Monday 9:30 Room 226

I can’t wait to see you all in Tallinn!

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!

This post was supposed to be published yesterday January 18th 2012, but I’m delaying it of 24 hours in support of SOPA STRIKE

Last weekend the Digikam Code Sprint was held in Genoa (Italy). Yes, I’m not a Digikam developer, but I live in Genoa and this was a very good occasion to implement something that I’ve being planning to implement for a long time: A KIPI Plugin for Telepathy. So before saying anything else, here is the mandatory screenshot:

Telepathy KIPI Plugin

Thanks to this plugin, you will be able to send your pictures and albums from digikam, showfoto and any other application using KIPI plugins. Most of all I wanted this feature in KSnapshot, and yes this is now possible.

This is something I already implemented in the past [1] but I must admit that having all the contacts in a menu was a bad idea, so I gave up at the time… So this time we have a widget instead that takes shows only the person that are online, that can accept a file transfer and there is a bar to filter by name (actually most of this is widget is “borrowed” from Telepathy Send File, written by David, so credits for that go to him). I think this solution is much better than the menu, but comments are very welcome.

Unfortunately the widget won’t be in KDE Telepathy 0.3 so you will have to wait for the 0.4 release, and then you will have to wait for the kipi-plugin to be reviewed by the digikam developers… Meanwhile it will reside in my clone repositories (I will update this post with the links as soon as the code is available)

Microsoft announced that they had added XMPP to their Windows Live APIs. Microsoft announced that they had added XMPP to their Windows Live APIs. That means that any Jabber client could connect to MSN using our favorite open IM protocol! No more closed protocol to reverse-engineer.

Since Gabble now supports it, I just had to add a little bit of magic to support the Messenger OAuth2 authentication in KDE-Telepathy Auth Handler and add a profile to the Account Manager. Microsoft implementation still have some problems (you cannot add/authorize new contact, yahoo contacts are not shown, etc.), therefore by default the “old” method will be used, but we think that it is important that people starts using it, therefore starting from KDE Telepathy 0.3 (that will be released the 25th of January) you will be able to use XMPP protocol with your MSN account.

It is important to notice that you can have just one MSN-XMPP account at the moment, so here is how to add it.

First of all, you have to add a new account from System Settings > Instant Messaging and VOIP > Accounts > Add Account > Others > choose the “MSN (using XMPP)” profile and click Next

MSN (using XMPP) profile

OAuth2 authentication is a little bit different from the normal authentication. You don’t have to set any parameter, just click “Finish” in the next tab.

Just click "Finish"...

Now the magic will happen and the Authorization Handler will popup with a dialog where you have to insert your Windows Live ID and your password, then click “Sign in”

Insert your Windows Live ID and your password, then click "Sign in"

Finally you will get another page where you have to authorize the application to connect, by clicking on “Yes”

Click "Yes"!!!

And you should be connected.

Have a nice chat!

P.S. Due to this bug, if you manage to connect the first time, but you fail later, try deleting the account and repeating those steps… [EDIT: Fixed before 0.3]

P.P.S. Thanks to Xavier for the support and the suggestions!

EDIT: MSN OAuth2 authentication requires telepathy-gabble >= 0.15.0

KDE-Telepathy Service Monitor

I find it quite useful, it allows you to choose the services you are interested in among the ones installed, monitor which services are running, start and stop them from the applet.
Moreover thanks to that I already found a bug in the auth-handler that doesn’t exit when it is supposed to do so, so I’m sharing the xml files hoping that they can be useful for someone else. If you are interested you can find them here: git://anongit.kde.org/scratch/ddomenichelli/telepathy-service-monitor, you just import the xml files from the “Manage Sources” tab in the config dialog for the applet.

P.S. All credits for Service Monitor go to the original author.

A few conclusive random thoughts about the sprint:

• We were the same number of people last year at the sprint. However in the last year the team gained several new important members!
• Opening new bugs is something that grundleborg can do damn fast.
• Sprints are really funny, and at the same time you get a lot of work done.
• Help is always needed! If you want to contribute, please join us on #kde-telepathy
• I won’t to wear the same shirt for the next sprint. (See here).
• Brasil and Australia are really far.
• Of course thanks again to Collabora and KDE e.V. for sponsoring the event.
• Nepomuk shall not die! Please support trueg and the Nepomuk project!

The morning started with several important stuff, discussions, etc. but around launch time the situation was this:

Almost all tasks and discussion completed!

Of course nobody will ever be able to satisfy the last! (I’m kidding, thanks alin for testing and reporting bugs )

In the afternoon we started implementing some of the features that we are planning for 0.2 release and we got some impressive results!

• nwoki fixed the audio call
• d_ed (also known as “the release manager”) implemented drag and drop of contacts to plasma desktop
• mck182 implemented the auto away system
• woshibon is now the official name for KDE-Telepathy sprints

Woshibon group photo

We had dinner at an indian restaurant and mck182 definitely ate something too spicy for him

Vindaloo is too spicy for mck182

At the moment the hacking is still going on in the lobby of our hotel, 5 people are connected to the internet using d_ed’s android phone as an access point… that’s cool!

Tomorrow is the last day of the sprint and the list of the new features in the 0.2 technical release should be available before the end of the day, hopefully together with some new features and perhaps a screencast?

Hacking outside Collabora office

Someone else spent his time in other ways…

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

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

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

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

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)

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

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

Send File Dialog

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

• Part 1: Contact List
• Part 2: Account Management
• Part 3: Presence Management
• Part 5: The Future

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

• 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

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

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

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

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!

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!

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!