Adding/Approving/Removing Contacts

Olli Salli olli.salli at collabora.co.uk
Fri Apr 1 12:52:09 CEST 2011


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 01.04.2011 03:44, Daniele E. Domenichelli wrote:
> On 03/31/2011 10:53 PM, David Edmundson wrote:
>> I think "add contact" should go in the contact list, as it makes sense
>> to open that to alter your contacts. Same for removing them.
>> (I have a patch for this, waiting on Martin's merge)
>> In future we have DrDanz's KJobs for doing this all with all the nepomuk
>> jazz, and my "add user dialog" could be made shareable.
> 
> Actually Dario wrote the add and remove contact jobs ;)
> 
> 
>> The issue is "approving contacts" (or to use the correct
>> term presencePublicationRequested) when someone else adds you. Telepathy
>> is always running and you may be signed in regardless of whether you
>> have the contact list open. In this happens someone needs to notify the
>> user of this event. 
>>
>> I was discussing with George K that this should go into the approver,
>> it's always running all the time and communicates via KNotify. It seems
>> a sensible choice (even the name fits)
> 
> +1
> 
> The only other process that should be running all the time is
> telepathy-nepomuk-service and It doesn't really fit there.
> 

But it does, see my other mail!

> Anyway what happens if you have two processes listening to the
> presencePublicationRequested signal? Is there any way to block the
> signal like with the approval of the channel or you will get two popups?
> 

Unfortunately, there is none. Approvers and Handlers are invoked by the
Channel Dispatcher using D-Bus method calls which naturally specify a
single destination, and the Chosen One can then be assured that nobody
else got the channel. However, as we're talking about D-Bus signals
here, anybody can see them. The CM sends exactly one signal, which can
be caught by any number of listeners for that signal.

Hence, the UI side needs to define clear roles for components, and that
just one component should be handling these kinds of signals by
pestering the user. And yeah, some kind of mechanism is needed to
deactivate our handling if Empathy's is active, and vice versa.

> 
> 
> Cheers,
>  Daniele
> _______________________________________________
> KDE-Telepathy mailing list
> KDE-Telepathy at kde.org
> https://mail.kde.org/mailman/listinfo/kde-telepathy

Br,
Olli
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJNla5ZAAoJEAQQkupGanj4GYQH/0jmmVW9jH1kBzJv7USDtmsO
wLyzieSPfBPFtWb9/5KWsIycA/uUq1tNQQKuQLRdQTcWW9Vp/pwz6o9mN8fRSWLe
LzUIVbssCnANXXEoh+3IfYIYGlT9oRTLEg82req6WZw40TRGbYO86PQkVLQl3bgX
hoS5p5WSs0ntSpS6Eky3TySDf8c31TVhKxjcse49UwkY7Anrt3rxgq0eNy0WKUby
B6w4mVu548x93/KUsXRpCAo7bxjYgxRMmJQaIAol87fj1zdo2ofKuGu2O23M0k+B
UHdNiZSRZJmGgRxz0u7n35JgPDmAdKkLalwKz1qLQuqU8DTPhVpoH0HwiaR54Ho=
=wzDm
-----END PGP SIGNATURE-----


More information about the KDE-Telepathy mailing list