<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
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.<br>
<br>
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.<br>
<br>
Also, the plugin is not currently caching any contacts, which would
be required in order to sync changes<br>
<br>
What about just getting the entire contact book every time the
plugin loads?<br>
<br>
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).<br>
<br>
Maybe just dump the phone numbers + names, then load contact photos
as the contact is actually used?<br>
<br>
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 :)<br>
<br>
Thanks,<br>
Simon<br>
<br>
<div class="moz-cite-prefix">On 05/15/2017 02:16 AM, Albert Vaca
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAAQViEtXGcGdQ-CJbPm+eOB-uRzXEsdLpBC70B_OiOz9fPw5oQ@mail.gmail.com">
<div dir="auto">Feel free to make any changes regarding comments,
refactoring, etc.
<div dir="auto"><br>
</div>
<div dir="auto">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? </div>
<div dir="auto"><br>
<div dir="auto">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 :)</div>
<div dir="auto"><br>
</div>
<div dir="auto">Albert</div>
</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On May 14, 2017 7:21 PM, "Simon Redman"
<<a href="mailto:simon@ergotech.com" moz-do-not-send="true">simon@ergotech.com</a>>
wrote:<br type="attribution">
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF"> I think the current
status of KDE Connect + Telepathy is "Solid, as long as
you don't touch anything"<br>
<br>
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!<br>
<br>
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. <br>
<br>
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?<br>
(Be sure to limit your outgoing messages to 160 bytes or
less until the other patches for the Android app get
merged in :) )<br>
<br>
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.<br>
<br>
At the same time, if the account is online in KTp, it will
relaunch connectcm if it gets killed.<br>
<br>
(It should be made clear at this point that, before
Friday, I had never worked with DBus, so I could be wildly
misunderstanding things)<br>
<br>
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!) <br>
<br>
Doing this and figuring out a better way of handling the
contacts book are probably the next two steps for the
Telepathy plugin.<br>
<br>
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?<br>
<br>
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 :/<br>
<br>
Thanks,<br>
Simon<br>
<br>
<div class="m_-6311593950993040245moz-cite-prefix">On
05/14/2017 04:21 AM, Albert Vaca wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">Hey Simon!
<div><br>
Thanks for your patches :) telepathy-kdeconnect is
indeed the proper repo.</div>
<div>
<div><br
class="m_-6311593950993040245gmail-Apple-interchange-newline">
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?</div>
</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>Albert</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Sat, May 13, 2017 at 9:11
AM, Simon Redman <span dir="ltr"><<a
href="mailto:simon@ergotech.com" target="_blank"
moz-do-not-send="true">simon@ergotech.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">Well,
I sure hope telepathy-kdeconnect is the latest,
because after much<br>
fiddling and reading of documents, I have figured
out how to make it<br>
launch reliably (for me!)<br>
<br>
I still don't fully understand why this solution
works, but the basic<br>
problem seemed to be that the connectcm plugin did
not claim to<br>
implement the kdeconnect (telepathy) protocol.
Adding this protocol<br>
information to kdeconnect.manager made the
complaints in Mission<br>
Control's log go away and lets the plugin
auto-load when I reboot!<br>
<br>
I submitted a patch to phabricator. Please let me
know if I should have<br>
done something with that submission differently!<br>
<br>
Thanks,<br>
Simon<br>
<div class="m_-6311593950993040245HOEnZb">
<div class="m_-6311593950993040245h5"><br>
On 05/12/2017 06:09 PM, Simon Redman wrote:<br>
> Hi,<br>
><br>
> What is the current status of the
telepathy plugin?<br>
><br>
> I am interested in looking into this and
I would love to see the<br>
> seamless integration into the existing
messenger tool, as opposed to the<br>
> current notifications system which I find
a bit intrusive<br>
><br>
> There seem to be two branches with names
involving telepathy of the main<br>
> kde-connect git repository, as well as
the git repository here:<br>
> <a
href="https://cgit.kde.org/telepathy-kdeconnect.git"
rel="noreferrer" target="_blank"
moz-do-not-send="true">https://cgit.kde.org/telepathy<wbr>-kdeconnect.git</a><br>
><br>
> Which is the latest? I assume
telepathy-kdeconnect.git, but assumptions<br>
> are dangerous!<br>
><br>
> There is talk of some progress in this
direction back in 2014:<br>
> <a
href="https://dot.kde.org/2014/04/29/kde-telepathy-sprint"
rel="noreferrer" target="_blank"
moz-do-not-send="true">https://dot.kde.org/2014/04/29<wbr>/kde-telepathy-sprint</a><br>
> As well as on the KDE Connect v1.0
announcement page:<br>
> <a
href="https://albertvaka.wordpress.com/2016/08/26/kde-connect-1-0-is-here/"
rel="noreferrer" target="_blank"
moz-do-not-send="true">https://albertvaka.wordpress.c<wbr>om/2016/08/26/kde-connect-1-0-<wbr>is-here/</a><br>
><br>
> Per the blog announcement, there was some
confusion about what order<br>
> things needed to be launched in. The
order which is consistently working<br>
> for me is: Launch KDE Connect Telepathy
Plugin (Which causes<br>
> mission-control to launch) then launch
KDE Connect<br>
><br>
> Thanks,<br>
> Simon<br>
><br>
<br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
</div>
</blockquote>
</div>
</div>
</blockquote>
<br>
</body>
</html>