So, this is a long story so I will try to keep it short.
- The phone-app running on ubuntu touch is a telepathy client.
- phone-app uses telepathy-qt to talk to telepathy.
- telepathy-ofono is a bridge between ofono and telepathy.
So far so good. The problem comes now:
- telepathy-ofono was initially developed in python and python-telepathy
- python-telepathy is deprecated in favor of pygobject
This means that we will eventually need to drop python-telepathy,
and this is why we are porting the current telepathy-ofono from python-telepathy
to telepathy-qt. Phone-app highly depends on telepathy-qt already, so this move
seems to be pretty reasonable.
But we have one more problem to solve: telepathy-qt does not provide full support
for connection managers, which is currently a big blocker.
Fortunately an initial (and working) support for telepathy connection managers was
added by Matthias Gehre. 
He implemented many telepathy service side interfaces and they seem to work fine.
Based on his implementation I’ve started to develop a new telepathy-ofono  a few weeks ago.
Using the same idea of the existing interfaces, I added support for some other interfaces
needed by phone-app, like the call channel interface (Channel.Type.Call1), call content (Call1.Content),
mute (Call.Interface.Mute) and hold (Channel.Interface.Hold). 
There are some other missing interfaces that I will be adding support in the next
few days, like DTMF (Call1.Content.Interface.DTMF).
I hope I can finish implementing everything soon so I can submit a merge proposal upstream later next
Ok, looks like we are good telepathy wise, but we still need to talk to ofono. Fortunately there is a project called ofono-qt 
that helps doing this job.
Nothing is perfect and looks like it is a bit outdated. The ofono api changed a bit since the last
commit to the project, so I updated some methods and I also intend to propose a merge upstream soon. 
That’s it. The new telepathy-ofono based on telepathy-qt is on its way.
I will finish this post with a small TODO list so it’s easier to understand what’s still missing
and what will be done next.
- Fix eventual crashes when clients close call channels
- Check why objects paths are still exposed on dbus even after the channel is closed
- Implement DTMF interface
- implement DTMF support
- implement custom voicemail properties
- implement online status support
GSoC is about to end. The good news is that I was able to finish my project, and the bad news is that I would like to have more time to implement more features than I proposed.
All the patches are committed to kopete svn (and libmsn) and trunk (crazy) users can already test them.
As I did not have time to blog (aka ‘I’m lazy to do so’), I am going to report all the status at once in only one post.
The goal was to add a small box where the user could draw something. The ink support will only be compiled if you have libgif. Some people cannot receive inks because they are using old MSN protocols, so the ink button will only be shown if the user is able to receive it correctly.
Voice Clips Support:
It was added to kopete a new action, so it is possible to play and save received and sent voice clips directly from the chat window.
The account properties window received new entries, and now it is possible to use a HTTP or a Socks5 proxy.
Three new options were added to better control the emoticons behavior.
1 – Do not send custom emoticons to other contacts.
2 – Do not show custom emoticons from other contacts.
3 – Block emoticons from a certain contact. (this one is in the last screenshot)
Contact List Improvements:
It is now possible to see contacts that deleted us from their lists. A red ‘x’ will be shown on the contact status icon.
Another improvement is that it is possible to refresh the avatar from any contact manually.
So that’s it. I would like to thank Google for the opportunity and specially my mentor Gustavo Boiko, who helped me a lot on my project. It was really amazing to be part of this program and I hope that my work can be useful to others.
well, this year I got accepted to Google Summer of Code and last week I started working on my proposal.
The first feature I suggested is the support to send Ink Draws, and I’m working on it right now.
Just for the record I’m posting here the first screenshot of what I have done so far.
Now the bad news:
MSN supports two kinds of image formats: Gif and Isf (Ink Serialized format, from Microsoft).
My first idea was to store the draw to a QImage (from qt4) and then save it to gif, but unfortunately there is no gif writing support in Qt. The Isf format is now open, and there is a library made by the aMSN people to manage the Isf images, but unfortunately third party clients still does not support Isf.
People from kopete-devel@ ML said that it is ok to link kopete to an external library (like giflib) to manage that, but the right approach was suggested by my mentor, that is to write a QImageIO plugin to deal with this gif stuff.
At the moment I’m busy fixing other bugs and adding some more stuff to the Ink plugin (pen color and size), but as soon as possible I will evaluate what is the best approach (giflib, QImageIO plugin, other? suggestions are welcome) considering my programming skills.
For now I’m using a dirty trick: I save the image in PNG and then.. well.. QProcess::exec(“convert old.png new.gif”);, but do not worry, I will not keep that in the code :)
Just for the record:
--------------------------------------------------- SVN commit 884493 by mattr: Enable the new WLM plugin for Kopete. This new plugin replaces the MSN plugin and requires an external library called libmsn which can be gotten from http://sourceforge.net/projects/libmsn We're working towards a 0.4 release of that library but until then, please download the beta versions. The new WLM plugin provides support for the MSNP15 protocol version and in general lays the groundwork for a better MSN plugin. Thanks go to Tiago Salem Herrmann, Gustavo Boiko, and Roman Jarosz for doing all the heavy lifting. --------------------------------------------------- \o/
Some months ago I tried to join GSoC (Google Summer of Code), but
unfortunately I was not accepted. Even this way I decided to keep working
on the project that I submitted as my proposal.
About two weeks ago I was notified that Google was going to send me
a swag because I completed my project even without being accepted.
Today when I got home I was suprised by a package coming from google.
My sincere thanks to google.
“May the source be with you..”
It’s been a long time I don’t write here, so it is time to update the wlm plugin and libmsn status.
Too much work has been done in wlm and libmsn since the last post. Boiko helped me on porting wlm plugin to kde4 + qt4 (thanks), The avatar management and identity integration was improved, file transfer works better now, some issues with blocking connection were fixed by changing libmsn layout, and so on.
Two weeks ago I sent the source code and the current status of libmsn and wlm plugin to kopete-devel@ mailing list. Some days after this Urs Wolfer and Olivier Goffart from #kopete channel helped me on getting an account in the kde svn and to upload the source code to kopete’s svn playground.
So the new (temporary, I hope) wlm home is here:
Last weeks I’ve been playing with kopete and libmsn.
I don’t know if it will become part of upstream kopete development,
but at least now I am able to send/receive files and offline messages.
Features up to this moment:
- send/receive regular messages
- send/receive offline messages
- file transfer.
- multi-chat (more than 2 people)
- display pictures transfer
- chat while in invisible mode
- “Listening to” and “Personal Messages” support
kopete TODO list:
- voice clip
- ink support
- improve address book management
- formatted messages (fonts and colors)
- winks (argh, I’m not sure about this one yet)
- custom emoticons (not sure about this one too =)
libmsn TODO list:
When I was developing RNAT I needed to change one kernel function (ip_options_compile), but I didn’t want the users to recompile their kernels. So then I discovered here that it was possible to hijack a kernel function by using a kernel module, and it solved my problem for that moment.
To exemplify the hijacking process, the code below shows how to hijack sys_mkdir() system call, preventing any user from creating a directory.
Don’t forget to change the old_sys_mkdir pointer to your real sys_mkdir() function.
——————- newmkdir.c —————-
static spinlock_t kern_lock = SPIN_LOCK_UNLOCKED;
unsigned long slock_flags;
#define LOCK_KERN spin_lock_irqsave(&kern_lock, slock_flags)
#define UNLOCK_KERN spin_unlock_irqrestore(&kern_lock, slock_flags)
static unsigned char pr_jump=”\xbf\x00\x00\x00\x00″ /* mov $0,%edi */
“\xff\xe7″; /* jmp *%edi */
static unsigned char pr_save;
unsigned char * old_sys_mkdir = (unsigned char *) 0xc01c79d0; /* grep sys_mkdir$ /proc/kallsyms */
/* function prototype from /usr/include/linux/syscalls.h */
asmlinkage long new_sys_mkdir(const char __user *pathname, int mode)
printk(“Tried to create: %s, mode: %d\n”, pathname, mode);
/* return Access Denied */
static int __init new_sys_mkdir_init(void)
/* fill pr_jump zero’s with the pointer to our new_sys_mkdir() */
*(long *)&pr_jump = (long)new_sys_mkdir;
/* replace the inital 7 bytes from the original sys_mkdir() with our jump to new_sys_mkdir() */
memcpy(pr_save, old_sys_mkdir, 7);
memcpy(old_sys_mkdir, pr_jump, 7);
static void __exit new_sys_mkdir_exit(void)
/* copy the old initial 7 bytes back */
memcpy(old_sys_mkdir, pr_save, 7);
——————– Makefile —————-
obj-m := newmkdir.o
KDIR := /lib/modules/`uname -r`/build
PWD := $(shell pwd)
$(MAKE) -C $(KDIR) SUBDIRS=$(PWD) modules
make -C /lib/modules/$(shell uname -r)/build M=$(PWD) clean
Last months I’ve been facing a weird Xorg problem: eventually the keyboard and mouse hangs.
The only thing I know is that a simple VT switch solves the problem. I was getting used to ssh my pc from another one and do a “chvt 1; chvt 7″, but yesterday Claudio suggested me to map one acpi event to do that, and it worked.
Now, when I lose the keyboard and mouse control, all I need to do is unplug the ac cable (it is a laptop) and plug it again.