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

[David Edmundson]

I love upstream.

Is this a viable option for our first release? It all sounds simple enough
except for the mc plugin. I have no idea how hard that is.

You said the applet should take the bus name. Can we expose this via the
data engine somehow?
On 15 Apr 2011 18:55, "George Goldberg" <grundleborg at googlemail.com> wrote:
> 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.
> _______________________________________________
> KDE-Telepathy mailing list
> KDE-Telepathy at kde.org
> https://mail.kde.org/mailman/listinfo/kde-telepathy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/kde-telepathy/attachments/20110415/177931bf/attachment-0001.htm