[Bug 270675] What to do about disconnecting when the contact list is closed

George Goldberg grundleborg at googlemail.com
Fri Apr 15 17:47:39 CEST 2011


https://bugs.kde.org/show_bug.cgi?id=270675





--- Comment #1 from George Goldberg <grundleborg googlemail com>  2011-04-15 17:47:38 ---
The solution lies upstream :)

It should be done as follows: 

1) Every UI capable of changing presence (defined as able to set accounts to
offline) registers for a unique DBus busname (with the queue flag set).
2) Mission Control checks that this bus name is not belonging to "nobody".
3) When this changes to "nobody" MC takes the accounts offline.

The result is that all accounts are taken offline when the user has no UI to
set them offline anymore.

To implement this the following is needed:
1) SPEC update to detail this, along with the busname that presence UI's should
try and take
2) Plasma applet and COntact List should take the busname.
3) MC plugin to take accounts offline when necessary.

IRC Logs
========
[16:38:43] <barisione> grundleborg: I dislike the idea of being online if there
is no running presence ui or contact list
[16:38:52] <grundleborg> barisione: exactly
[16:39:17] <grundleborg> barisione: but we want to find a way to implement it
withough having to say "YOU MUST USE PRESENCE UI $X and when you quit it, you
will go offline"
[16:40:28] <smcv> grundleborg: have all presence UIs (including contact lists)
take a particular bus name, setting the "I don't mind queueing" flag; if that
name has no owner, go offline?
[16:41:04] <grundleborg> smcv: intriguing - I didn't know this was possible
[16:41:16] <smcv> that would lead to the UI being "if I have no way to ask to
be offline, then put me offline"
[16:41:33] <grundleborg> smcv: i guess we'd have to agree this with all
presence apps, not just KDE ones though. perhaps part of telepathy-spec?
[16:41:41] <grundleborg> smcv: that's the desired affect, I think
[16:42:20] <smcv> grundleborg: yeah, in GNOME-land I think Empathy and GNOME
Shell would be the things that tried to claim the name
[16:42:33] <smcv> one thing to watch out for: dbus-daemon allows atomic
replacement
[16:42:57] <smcv> so if Empathy owns the name, and quits, and GNOME Shell is in
the queue, the owner can flip straight from Empathy to Shell without ever being
"nobody"
[16:43:12] <grundleborg> smcv: would that be a problem?
[16:43:37] <smcv> but it wouldn't surprise me if some client APIs "simplified"
that to "owner changes to nobody, then Shell picks it up"
[16:44:01] <smcv> the atomic replacement thing is necessary for the
implementation I suggested
[16:44:23] <grundleborg> oh i see
[16:44:42] <oggis_> smcv: oh, is the "I don't mind queueing" implemented by the
client binding starting to wait for NameOwnerChanged to nothing?
[16:44:47] <smcv> g_bus_watch_name() makes that similification, for instance
[16:44:54] <smcv> oggis_: no, dbus-daemon contains a queue
[16:45:29] <smcv> the thing that would put accounts offline when no more UIs
existed (presumably MC or a plugin) wouldn't be able to use a "simplified" API
like g_bus_watch_name though
[16:45:32] <sjoerd> gnome-shell isn't a great presence monitor btw, it doesn't
tell whether any accounts are actually online or if there are which ones
[16:45:33] <oggis_> smcv: thought so - then is there a problem? surely the bus
daemon would only give the name to the first one in the queue
[16:45:38] <smcv> they'd have to use something that exposed atomic changes
[16:45:55] <sjoerd> It's just a, you told me your available/busy, it doesn't
show any IM state
[16:46:04] <smcv> sjoerd: yeah, bad example then
[16:46:21] <smcv> in Ubuntu, either Empathy or the Unity messaging menu would
count, maybe
[16:46:36] <smcv> but Shell probably shouldn't, unless it makes it a little
more obvious that you're online
[16:47:07] <smcv> perhaps the right rule of thumb is "if it has a 'go offline'
option then it's a good enough presence UI", which would rule out current Shell
[16:47:11] <grundleborg> smcv: so should I read that as your solution is not
actually possible beacuse of the DBus client API's?
[16:47:26] <smcv> grundleborg: oh it's possible, you just have to be a little
careful
[16:47:34] <grundleborg> right
[16:47:37] <oggis_> smcv: if you queued for the name when starting, and when
exiting first released the name, then checked by a separate GetNameOwner call
(not by watching listening to NameOwnerChanged on the well-known name) and if
there is no owner, disconnect, wouldn't it work despite any client-side
simplifications?
[16:47:54] <oggis_> -watching
[16:48:00] <smcv> the MC plugin or whatever would have to avoid
g_dbus_watch_name and go directly to the D-Bus-level signal
[16:48:11] <grundleborg> smcv: and are you suggesting that MC be modified to do
this "setting offline if that bus name is not taken", or are you saying it
should be done somewhere else?
[16:48:15] <grundleborg> ah
[16:48:15] <smcv> oggis_: oh I see, so make the disconnecting cooperative
between all the UIs?
[16:48:20] <grundleborg> you answered my question already
[16:48:38] <oggis_> smcv: that'd work, and there aren't that many presence UIs
to cooperate with so it could be the way to go
[16:48:45] <smcv> grundleborg: I was assuming MC would do it (because that way,
if all your presence UIs crash, you aren't secretly online after all)
[16:49:01] <oggis_> umm, yes, them crashing is one thing.
[16:49:02] <grundleborg> oggis_: it'd still think it's simpler to do in MC if
possible
[16:49:13] <oggis_> grundleborg: yes
[16:49:31] <smcv> it could work either way
[16:49:46] <grundleborg> excellent... sounds like we have a viable solution :)
[16:50:44] <oggis_> I like the MC solution more as well though
[16:50:50] <oggis_> now that I think of it
[16:51:13] <oggis_> that way the only thing the presence UIs need to cooperate
on is that specific service name and queueing for it
[16:51:34] <oggis_> not the correct sequence of checking whether they need to
disconnect the accounts on exit

-- 
Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.


More information about the KDE-Telepathy mailing list