Replacing python-telepathy with telepathy-qt on Ubuntu-touch
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
2 Comments »