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" <[email protected]> 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 > [email protected] > https://mail.kde.org/mailman/listinfo/kde-telepathy
_______________________________________________ KDE-Telepathy mailing list [email protected] https://mail.kde.org/mailman/listinfo/kde-telepathy
