<p>I love upstream. </p>
<p>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.</p>
<p>You said the applet should take the bus name. Can we expose this via the data engine somehow?</p>
<div class="gmail_quote">On 15 Apr 2011 18:55, "George Goldberg" <<a href="mailto:grundleborg@googlemail.com">grundleborg@googlemail.com</a>> wrote:<br type="attribution">> <a href="https://bugs.kde.org/show_bug.cgi?id=270675">https://bugs.kde.org/show_bug.cgi?id=270675</a><br>
> <br>> <br>> <br>> <br>> <br>> --- Comment #1 from George Goldberg <grundleborg googlemail com> 2011-04-15 17:47:38 ---<br>> The solution lies upstream :)<br>> <br>> It should be done as follows: <br>
> <br>> 1) Every UI capable of changing presence (defined as able to set accounts to<br>> offline) registers for a unique DBus busname (with the queue flag set).<br>> 2) Mission Control checks that this bus name is not belonging to "nobody".<br>
> 3) When this changes to "nobody" MC takes the accounts offline.<br>> <br>> The result is that all accounts are taken offline when the user has no UI to<br>> set them offline anymore.<br>> <br>> To implement this the following is needed:<br>
> 1) SPEC update to detail this, along with the busname that presence UI's should<br>> try and take<br>> 2) Plasma applet and COntact List should take the busname.<br>> 3) MC plugin to take accounts offline when necessary.<br>
> <br>> IRC Logs<br>> ========<br>> [16:38:43] <barisione> grundleborg: I dislike the idea of being online if there<br>> is no running presence ui or contact list<br>> [16:38:52] <grundleborg> barisione: exactly<br>
> [16:39:17] <grundleborg> barisione: but we want to find a way to implement it<br>> withough having to say "YOU MUST USE PRESENCE UI $X and when you quit it, you<br>> will go offline"<br>> [16:40:28] <smcv> grundleborg: have all presence UIs (including contact lists)<br>
> take a particular bus name, setting the "I don't mind queueing" flag; if that<br>> name has no owner, go offline?<br>> [16:41:04] <grundleborg> smcv: intriguing - I didn't know this was possible<br>
> [16:41:16] <smcv> that would lead to the UI being "if I have no way to ask to<br>> be offline, then put me offline"<br>> [16:41:33] <grundleborg> smcv: i guess we'd have to agree this with all<br>
> presence apps, not just KDE ones though. perhaps part of telepathy-spec?<br>> [16:41:41] <grundleborg> smcv: that's the desired affect, I think<br>> [16:42:20] <smcv> grundleborg: yeah, in GNOME-land I think Empathy and GNOME<br>
> Shell would be the things that tried to claim the name<br>> [16:42:33] <smcv> one thing to watch out for: dbus-daemon allows atomic<br>> replacement<br>> [16:42:57] <smcv> so if Empathy owns the name, and quits, and GNOME Shell is in<br>
> the queue, the owner can flip straight from Empathy to Shell without ever being<br>> "nobody"<br>> [16:43:12] <grundleborg> smcv: would that be a problem?<br>> [16:43:37] <smcv> but it wouldn't surprise me if some client APIs "simplified"<br>
> that to "owner changes to nobody, then Shell picks it up"<br>> [16:44:01] <smcv> the atomic replacement thing is necessary for the<br>> implementation I suggested<br>> [16:44:23] <grundleborg> oh i see<br>
> [16:44:42] <oggis_> smcv: oh, is the "I don't mind queueing" implemented by the<br>> client binding starting to wait for NameOwnerChanged to nothing?<br>> [16:44:47] <smcv> g_bus_watch_name() makes that similification, for instance<br>
> [16:44:54] <smcv> oggis_: no, dbus-daemon contains a queue<br>> [16:45:29] <smcv> the thing that would put accounts offline when no more UIs<br>> existed (presumably MC or a plugin) wouldn't be able to use a "simplified" API<br>
> like g_bus_watch_name though<br>> [16:45:32] <sjoerd> gnome-shell isn't a great presence monitor btw, it doesn't<br>> tell whether any accounts are actually online or if there are which ones<br>> [16:45:33] <oggis_> smcv: thought so - then is there a problem? surely the bus<br>
> daemon would only give the name to the first one in the queue<br>> [16:45:38] <smcv> they'd have to use something that exposed atomic changes<br>> [16:45:55] <sjoerd> It's just a, you told me your available/busy, it doesn't<br>
> show any IM state<br>> [16:46:04] <smcv> sjoerd: yeah, bad example then<br>> [16:46:21] <smcv> in Ubuntu, either Empathy or the Unity messaging menu would<br>> count, maybe<br>> [16:46:36] <smcv> but Shell probably shouldn't, unless it makes it a little<br>
> more obvious that you're online<br>> [16:47:07] <smcv> perhaps the right rule of thumb is "if it has a 'go offline'<br>> option then it's a good enough presence UI", which would rule out current Shell<br>
> [16:47:11] <grundleborg> smcv: so should I read that as your solution is not<br>> actually possible beacuse of the DBus client API's?<br>> [16:47:26] <smcv> grundleborg: oh it's possible, you just have to be a little<br>
> careful<br>> [16:47:34] <grundleborg> right<br>> [16:47:37] <oggis_> smcv: if you queued for the name when starting, and when<br>> exiting first released the name, then checked by a separate GetNameOwner call<br>
> (not by watching listening to NameOwnerChanged on the well-known name) and if<br>> there is no owner, disconnect, wouldn't it work despite any client-side<br>> simplifications?<br>> [16:47:54] <oggis_> -watching<br>
> [16:48:00] <smcv> the MC plugin or whatever would have to avoid<br>> g_dbus_watch_name and go directly to the D-Bus-level signal<br>> [16:48:11] <grundleborg> smcv: and are you suggesting that MC be modified to do<br>
> this "setting offline if that bus name is not taken", or are you saying it<br>> should be done somewhere else?<br>> [16:48:15] <grundleborg> ah<br>> [16:48:15] <smcv> oggis_: oh I see, so make the disconnecting cooperative<br>
> between all the UIs?<br>> [16:48:20] <grundleborg> you answered my question already<br>> [16:48:38] <oggis_> smcv: that'd work, and there aren't that many presence UIs<br>> to cooperate with so it could be the way to go<br>
> [16:48:45] <smcv> grundleborg: I was assuming MC would do it (because that way,<br>> if all your presence UIs crash, you aren't secretly online after all)<br>> [16:49:01] <oggis_> umm, yes, them crashing is one thing.<br>
> [16:49:02] <grundleborg> oggis_: it'd still think it's simpler to do in MC if<br>> possible<br>> [16:49:13] <oggis_> grundleborg: yes<br>> [16:49:31] <smcv> it could work either way<br>
> [16:49:46] <grundleborg> excellent... sounds like we have a viable solution :)<br>> [16:50:44] <oggis_> I like the MC solution more as well though<br>> [16:50:50] <oggis_> now that I think of it<br>
> [16:51:13] <oggis_> that way the only thing the presence UIs need to cooperate<br>> on is that specific service name and queueing for it<br>> [16:51:34] <oggis_> not the correct sequence of checking whether they need to<br>
> disconnect the accounts on exit<br>> <br>> -- <br>> Configure bugmail: <a href="https://bugs.kde.org/userprefs.cgi?tab=email">https://bugs.kde.org/userprefs.cgi?tab=email</a><br>> ------- You are receiving this mail because: -------<br>
> You are the assignee for the bug.<br>> _______________________________________________<br>> KDE-Telepathy mailing list<br>> <a href="mailto:KDE-Telepathy@kde.org">KDE-Telepathy@kde.org</a><br>> <a href="https://mail.kde.org/mailman/listinfo/kde-telepathy">https://mail.kde.org/mailman/listinfo/kde-telepathy</a><br>
</div>