Summary: | What to do about disconnecting when the contact list is closed | ||
---|---|---|---|
Product: | [Unmaintained] telepathy | Reporter: | George Goldberg <grundleborg> |
Component: | contactlist | Assignee: | Telepathy Bugs <kde-telepathy-bugs> |
Status: | RESOLVED LATER | ||
Severity: | normal | CC: | mklapetek |
Priority: | NOR | ||
Version: | unspecified | ||
Target Milestone: | 0.4.0 | ||
Platform: | Unlisted Binaries | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | ||
Sentry Crash Report: | |||
Bug Depends on: | |||
Bug Blocks: | 232378 |
Description
George Goldberg
2011-04-11 12:25:56 UTC
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 What is the upstream state of this issue? Is there a bug/wish somewhere on fd.o that we could add here for tracking purposes? Git commit d175fb4c746cfe564b515fb37bf0c0637183e9f8 by Martin Klapetek. Committed on 13/07/2011 at 17:46. Pushed by mklapetek into branch 'master'. Check for Presence Plasmoid over D-Bus and warn user if the plasmoid is not active. CCBUG: 270675 REVIEW: 101918 Reviewed-by: David Edmundson M +81 -3 main-widget.cpp M +4 -0 main-widget.h http://commits.kde.org/telepathy-contact-list/d175fb4c746cfe564b515fb37bf0c0637183e9f8 I did a simple workaround - DataEngine now exports itself on D-Bus when active, contact list checks for this D-Bus path upon exit. If the path exists, contact list exits silently, if not, it asks user what to - go offline or stay online. I'm closing this for now so it doesn't confuse use in the release tracker bug. Later we'll revise this once upstream has the proper fixes in place. |