What is the status of the telepathy plugin

Albert Vaca albertvaka at gmail.com
Tue May 23 20:11:26 UTC 2017


I'm not knowledgeable enough about KTp to do a meaningful review, so I'm
adding David Edmundson (who started the kdeconnect telpathy plugin) as a
reviewer.

Once you get them approved and merged, I think you should apply for a
developer account with commit rights (so I don't have to merge your patches
anymore :).

On Tue, May 23, 2017 at 6:39 AM, Simon Redman <simon at ergotech.com> wrote:

> I finally kicked something enough that the option to add a kdeconnect
> account shows up in Empathy (but still not in KTp... I can't figure out
> why), so step one to "Support multiple devices by having one account per
> device" is done.
>
> There are two smaller revision requests and one mega request... Sorry
> about the very large one -- for a long time everything was broken because I
> specified a required parameter to the account but then never set it, so I
> was just reading documentation and tweaking things trying to figure out why
> the plugin was not loading.
>
> Thanks,
> Simon
>
>
> On 05/21/2017 04:57 AM, Albert Vaca wrote:
>
> And support for multiple devices looks like something you will end up
> needing. For other Telepathy plugins you can already have several accounts
> for the same plugin, so I guess it will be something like that... no idea
> how easy it is to implement it, though.
>
> Syncing the entire contact book every time the plugin loads and/or the
> contact list changes on Android seems ok. Specially if you start without
> syncing the profile pictures. Sounds like a good idea to sync first names
> and numbers and then sync the pictures later as you need them.
>
> Make sure, though, that when you fetch the contacts on Android you do a
> single query to the contact storage to retrieve them all. Since Android
> uses sqlite internally, doing a query per user is super slow.
>
> About maintaining the plugin, of course I will be more than happy to help
> you and review the patches :)
>
> On May 19, 2017 23:10, "Simon Redman" <simon at ergotech.com> wrote:
>
>> I will look into how other Telepathy plugins deal with contacts. Maybe
>> there is a very easy way to deal with caching, or maybe they just load the
>> whole contacts list when the plugin loads.
>>
>> The problems with the app watching for changes is I have a desktop and a
>> laptop which are not both always connected to the phone. The phone would
>> have to keep track of changes and which synchronized device has seen those
>> changes (Which is not impossible, but I'm lazy :) ) -- And, of course,
>> different phones may have different contacts books... Maybe I need to add
>> support for different devices sooner rather than later.
>>
>> Also, the plugin is not currently caching any contacts, which would be
>> required in order to sync changes
>>
>> What about just getting the entire contact book every time the plugin
>> loads?
>>
>> Since we have not defined what makes up a contact, it's a little hard to
>> make a guess of how expensive this would be. Regardless of how much text is
>> there, the picture is going to be the prime contributor to size... Say
>> 50KB? Meaning if you have more than say 100 contacts the plugin could take
>> a few seconds to load (over WiFi).
>>
>> Maybe just dump the phone numbers + names, then load contact photos as
>> the contact is actually used?
>>
>> If nobody else is currently maintaining this plugin, I would be happy to
>> take ownership. But would it be okay if I still forwarded at least the
>> first few patches through you for review? You've been working on this
>> project for far longer, so you're more likely to catch bugs, like my dumb
>> 160 letters vs. 160 bytes from my Android patches :)
>>
>> Thanks,
>> Simon
>>
>> On 05/15/2017 02:16 AM, Albert Vaca wrote:
>>
>> Feel free to make any changes regarding comments, refactoring, etc.
>>
>> Also, I agree that without the addressbook it is not very useful to be
>> able to send SMS. We can have the Android app listening for addressbook
>> changes and then sending it to the desktop, but I have no idea on how to
>> pass them to KTP. Any ideas?
>>
>> Actually, since I don't use KTP, there is no one actively maintaining the
>> kdeconnect plugin. If you want to step in, I would be more than happy to
>> let you own it :)
>>
>> Albert
>>
>> On May 14, 2017 7:21 PM, "Simon Redman" <simon at ergotech.com> wrote:
>>
>>> I think the current status of KDE Connect + Telepathy is "Solid, as long
>>> as you don't touch anything"
>>>
>>> Basically, I think the current problem is KTp will load the KDE Connect
>>> Telepathy plugin as soon as the kdeconnect account goes online, but the
>>> only tool we currently have to put the account online is the plugin!
>>>
>>> If you launch the plugin manually, any order of launching KDE Connect,
>>> Mission Control, or the plugin seem to work. I was also having a problem
>>> with the order of launching before, but that seems to have gone away just
>>> by adding those lines to the manager file.
>>>
>>> Could you (and others!) give this a test with the version of the plugin
>>> just pushed to the repositories and see if it works for you?
>>> (Be sure to limit your outgoing messages to 160 bytes or less until the
>>> other patches for the Android app get merged in :) )
>>>
>>> DBus seems to be doing the heavy lifting for me there when I first boot
>>> (or maybe login, I haven't looked) and launching connectcm, so then
>>> everything works (for me!) out-of-the-box, provided I don't kill connectcm.
>>>
>>> At the same time, if the account is online in KTp, it will relaunch
>>> connectcm if it gets killed.
>>>
>>> (It should be made clear at this point that, before Friday, I had never
>>> worked with DBus, so I could be wildly misunderstanding things)
>>>
>>> Probably the correct answer to this situation is to have the main KDE
>>> Connect application request Telepathy to put the kdeconnect account online
>>> when KDE Connect detects a connected phone, and have it request to put the
>>> kdeconnect account offline when no phone is connected. This would have the
>>> two advantages of making the Telepathy plugin load, and stopping the user
>>> from sending SMS messages while the phone is disconnected (Which currently
>>> just fires and SMS into the void, without any notification that something
>>> is wrong!)
>>>
>>> Doing this and figuring out a better way of handling the contacts book
>>> are probably the next two steps for the Telepathy plugin.
>>>
>>> Do you have any thoughts for how to get the contacts book from the
>>> phone, or a different way to get contacts rather than manually adding raw
>>> phone numbers?
>>>
>>> Would it be useful for me to upload patches for header comments to
>>> methods as I work through and figure out what they do? The current state of
>>> commenting is quite difficult to understand for someone who has never
>>> looked at this project :/
>>>
>>> Thanks,
>>> Simon
>>>
>>> On 05/14/2017 04:21 AM, Albert Vaca wrote:
>>>
>>> Hey Simon!
>>>
>>> Thanks for your patches :) telepathy-kdeconnect is indeed the proper
>>> repo.
>>>
>>> When I first tested telepathy-kdeconnect a while ago, I also found that
>>> the order in which you run the different daemons was important to make it
>>> work, and it looked overall a bit fragile. Maybe we can fix that somehow?
>>>
>>> Phabricator is the preferred tool for submitting patches, you did it
>>> right :) I see you created your KDE Identity recently, so I assume you
>>> don't have commit rights. I will merge this fix on your behalf.
>>>
>>> Albert
>>>
>>> On Sat, May 13, 2017 at 9:11 AM, Simon Redman <simon at ergotech.com>
>>> wrote:
>>>
>>>> Well, I sure hope telepathy-kdeconnect is the latest, because after much
>>>> fiddling and reading of documents, I have figured out how to make it
>>>> launch reliably (for me!)
>>>>
>>>> I still don't fully understand why this solution works, but the basic
>>>> problem seemed to be that the connectcm plugin did not claim to
>>>> implement the kdeconnect (telepathy) protocol. Adding this protocol
>>>> information to kdeconnect.manager made the complaints in Mission
>>>> Control's log go away and lets the plugin auto-load when I reboot!
>>>>
>>>> I submitted a patch to phabricator. Please let me know if I should have
>>>> done something with that submission differently!
>>>>
>>>> Thanks,
>>>> Simon
>>>>
>>>> On 05/12/2017 06:09 PM, Simon Redman wrote:
>>>> > Hi,
>>>> >
>>>> > What is the current status of the telepathy plugin?
>>>> >
>>>> > I am interested in looking into this and I would love to see the
>>>> > seamless integration into the existing messenger tool, as opposed to
>>>> the
>>>> > current notifications system which I find a bit intrusive
>>>> >
>>>> > There seem to be two branches with names involving telepathy of the
>>>> main
>>>> > kde-connect git repository, as well as the git repository here:
>>>> > https://cgit.kde.org/telepathy-kdeconnect.git
>>>> >
>>>> > Which is the latest? I assume telepathy-kdeconnect.git, but
>>>> assumptions
>>>> > are dangerous!
>>>> >
>>>> > There is talk of some progress in this direction back in 2014:
>>>> > https://dot.kde.org/2014/04/29/kde-telepathy-sprint
>>>> > As well as on the KDE Connect v1.0 announcement page:
>>>> > https://albertvaka.wordpress.com/2016/08/26/kde-connect-1-0-is-here/
>>>> >
>>>> > Per the blog announcement, there was some confusion about what order
>>>> > things needed to be launched in. The order which is consistently
>>>> working
>>>> > for me is: Launch KDE Connect Telepathy Plugin (Which causes
>>>> > mission-control to launch) then launch KDE Connect
>>>> >
>>>> > Thanks,
>>>> > Simon
>>>> >
>>>>
>>>>
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdeconnect/attachments/20170523/72b302a8/attachment-0001.html>


More information about the KDEConnect mailing list