Launchpad has imported 13 comments from the remote bug at https://bugs.freedesktop.org/show_bug.cgi?id=38366.
If you reply to an imported comment from within Launchpad, your comment will be sent to the remote bug automatically. Read more about Launchpad's inter-bugtracker facilities at https://help.launchpad.net/InterBugTracking. ------------------------------------------------------------------------ On 2011-06-16T11:13:29+00:00 Guillaume-desmottes wrote: As discussed [1] during the IM hackfest, Busy may not be the best fallback if invisible/hidden is not implemented. It should fallback to offline instead so a "Online / Invisible" switch is enough to easily control our visibility on IM. [1] https://live.gnome.org/Hackfests/IMContacts%20Social2011/Tasks/ShellDesignPresence Reply at: https://bugs.launchpad.net/empathy/+bug/881219/comments/0 ------------------------------------------------------------------------ On 2011-06-16T15:03:41+00:00 Marco-barisione wrote: Do you really want that? If I go invisible I still want to receive messages and be able to write to people, but if mc silently puts me offline I cannot do it anymore. Reply at: https://bugs.launchpad.net/empathy/+bug/881219/comments/1 ------------------------------------------------------------------------ On 2011-06-16T16:13:56+00:00 Guillaume-desmottes wrote: This will just be with accounts not supporting invisible: - link-local - Facebook - IRC - Some shitty XMPP servers Reply at: https://bugs.launchpad.net/empathy/+bug/881219/comments/2 ------------------------------------------------------------------------ On 2011-06-16T16:41:12+00:00 Simon McVittie wrote: The right fallback from invisible is somewhat situational. When you set your RequestedPresence to invisible, I think offline is probably the right fallback; you wanted to be invisible and are willing to sacrifice some connectivity to get it. If your AutomaticPresence is invisible and you're connecting in order to request a channel, the fallback needs to be Busy or Away: whenever you go online with automatic presence, the important thing is that you're online, and the fact that it's with automatic presence is secondary. The other thing that AutomaticPresence does is that it's what is requested if ConnectAutomatically is true and connectivity becomes available, but because we don't have useful connectivity plugins yet (see Bug #24762), that's not directly relevant right now. For the "eagerly go online when NetworkManager says we can" use-case, I think offline is the right fallback if invisibility is impossible. Complicating this is the fact that on XMPP, we can't tell whether we're going to be able to be invisible til halfway through connecting. Gabble should grow some way to distinguish between "invisible if possible" and "invisible and I really mean it" - Gabble can do the latter reliably (even though MC can't), by disconnecting before sending initial presence if it looks as though invisibility isn't going to work. However, it needs to know whether to do that - for the "about to request a channel" case, that'd be counter-productive. Perhaps MC could temporarily insert {"online-even-if-visible": TRUE} into the Parameters, if supported by the CM, when putting an account online for a channel request? For bonus points, every time we go online MC could remember whether invisibility works, so we can just stay offline next time we want to be invisible. Reply at: https://bugs.launchpad.net/empathy/+bug/881219/comments/3 ------------------------------------------------------------------------ On 2011-06-16T16:44:16+00:00 Simon McVittie wrote: (In reply to comment #3) > whenever you go > online with automatic presence, the important thing is that you're online This is not true, as demonstrated by the paragraph that followed it. What I really meant is "whenever you go online to request a channel". Reply at: https://bugs.launchpad.net/empathy/+bug/881219/comments/4 ------------------------------------------------------------------------ On 2011-06-16T16:56:29+00:00 Simon McVittie wrote: Some plausible use cases for being genuinely offline as far as IM is concerned: * I really, really don't want to be disturbed (but still need a web browser) * I'm on a sufficiently flaky network connection that if you send me a message there's a good chance it'll just get lost (most IM protocols don't have application-level acks, so there's a ~30 second window of message loss every time you drop off the overloaded conference wifi) * Using a particular network connection for some/all IM protocols is expensive (either in terms of money or battery capacity - 3G can be both!) Reply at: https://bugs.launchpad.net/empathy/+bug/881219/comments/5 ------------------------------------------------------------------------ On 2011-06-20T13:57:48+00:00 Guillaume-desmottes wrote: (In reply to comment #3) > If your AutomaticPresence is invisible and you're connecting in order to > request a channel, the fallback needs to be Busy or Away: whenever you go > online with automatic presence, the important thing is that you're online, and > the fact that it's with automatic presence is secondary. Is there any client actually using that feature? Reply at: https://bugs.launchpad.net/empathy/+bug/881219/comments/6 ------------------------------------------------------------------------ On 2011-06-27T09:35:48+00:00 Guillaume-desmottes wrote: Humm falling back to Offline instead of Busy is actually more complicated that I would have hoped. Not being able to call SetPresence('offline') introduces asymetry in the code. :( Reply at: https://bugs.launchpad.net/empathy/+bug/881219/comments/7 ------------------------------------------------------------------------ On 2011-06-27T10:01:11+00:00 Guillaume-desmottes wrote: Here is my not classy but working patch. http://cgit.collabora.com/git/user/cassidy/telepathy-mission-control/log/?h=offline-38366 Reply at: https://bugs.launchpad.net/empathy/+bug/881219/comments/8 ------------------------------------------------------------------------ On 2011-06-27T10:01:27+00:00 Guillaume-desmottes wrote: Created attachment 48456 Fallback to Offline instead of Busy if Hidden is not supported (#38366) That makes more sense as if you really want to be invisible you should be ready to sacrifice some connectivity to get it. Reply at: https://bugs.launchpad.net/empathy/+bug/881219/comments/9 ------------------------------------------------------------------------ On 2011-06-28T10:21:24+00:00 Simon McVittie wrote: (In reply to comment #6) > (In reply to comment #3) > > If your AutomaticPresence is invisible and you're connecting in order to > > request a channel > > Is there any client actually using that feature? I think it's the right thing for collaborative applications: if I say "share this document" in AbiWord, it should be able to offer me an account chooser and fire off a TpAccountChannelRequest with no further MC interaction, even if I'm not currently online. But if you think this feature is useless, I'd still like a regression test that demonstrates that MC does something vaguely sensible instead of crashing (i.e. the channel request fails, probably). Regression tests that this feature should have include: * be online, go invisible (via RequestedPresence), connection doesn't support it, fall back to disconnecting * be offline, AutomaticPresence = invisible, go online for a channel request, connection doesn't support it, either Disconnect() is called without calling Connect (request fails gracefully [1]) or the fallback is to busy * be offline, go invisible (via RequestedPresence), connection doesn't support it [2], Disconnect() is called without first calling Connect() [1] We'd probably need a new error, WouldBreakInvisibility? Or you could remove the feature entirely and only allow channel requests on online accounts, but that would make me very sad. [2] This won't do what you hope it does - Gabble can't announce definite support for invisibility until it has nearly finished connecting. So we probably need Gabble changes, to make it always allow setting invisible presence before going online, then if it discovers lack of invisibility support, disconnect with WouldBreakInvisibility instead of sending initial presence. Reply at: https://bugs.launchpad.net/empathy/+bug/881219/comments/10 ------------------------------------------------------------------------ On 2011-06-28T17:28:59+00:00 Will Thompson wrote: (In reply to comment #10) > (In reply to comment #6) > > (In reply to comment #3) > > > If your AutomaticPresence is invisible and you're connecting in order to > > > request a channel > > > > Is there any client actually using that feature? > > I think it's the right thing for collaborative applications: if I say "share > this document" in AbiWord, it should be able to offer me an account chooser > and > fire off a TpAccountChannelRequest with no further MC interaction, even if I'm > not currently online. Account chooser? Surely a contact chooser. And to show a contact chooser with relevant contacts in it, it needs to be online for caps... :) Reply at: https://bugs.launchpad.net/empathy/+bug/881219/comments/11 ------------------------------------------------------------------------ On 2012-02-01T14:40:32+00:00 Guillaume-desmottes wrote: http://cgit.collabora.com/git/user/cassidy/telepathy-mission- control/log/?h=offline-38366 now contains tests (covering the 3 scenarios you described) and a couple of fixes. I didn't add a new error as that will require changing the spec first but can easily do it once we agree that's the right approach. Reply at: https://bugs.launchpad.net/empathy/+bug/881219/comments/17 -- You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is subscribed to empathy in Ubuntu. https://bugs.launchpad.net/bugs/881219 Title: Empathy switches from "invisible" to "away" when monitor goes into power-saving mode or screen is locked To manage notifications about this bug go to: https://bugs.launchpad.net/empathy/+bug/881219/+subscriptions -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
