13-08-2009 17:07:07 > andrunko: smcv, so regarding the presence status thing, we have the following problem, user is busy on xmpp, sets invisible, the CM sets to busy again, but don't emit currentPresenceChanged, so the UI is there with a message "Updating presence..."
13-08-2009 17:07:42 > andrunko: on tp-qt4 we can just remove the check "if (currentPresence == what we received) do not emit currentPresenceChanged"
13-08-2009 17:07:43 < smcv!n=smcv@figment.pseudorandom.co.uk: +andrunko: the current presence never changed
13-08-2009 17:08:05 < smcv!n=smcv@figment.pseudorandom.co.uk: +andrunko: there was no moment at which the current presence was invisible
13-08-2009 17:08:06 > andrunko: but a user selected invisible in a combobox
13-08-2009 17:08:11 < smcv!n=smcv@figment.pseudorandom.co.uk: +andrunko: only the RequestedPresence ever changed
13-08-2009 17:08:16 > andrunko: and believes it's invisible, but he is not
13-08-2009 17:08:54 < smcv!n=smcv@figment.pseudorandom.co.uk: +perhaps Account needs a RequestPresence method, that returns what actually happened
13-08-2009 17:09:03 < smcv!n=smcv@figment.pseudorandom.co.uk: +file a bug
13-08-2009 17:09:07 > andrunko: ok
13-08-2009 17:09:17 < smcv!n=smcv@figment.pseudorandom.co.uk: +(callers would need to set a ~infinite timeout, though)
13-08-2009 17:09:42 < smcv!n=smcv@figment.pseudorandom.co.uk: +or perhaps MC should set RequestedPresence to the closest thing to the achievable presence? that seems strange though
13-08-2009 17:09:53 < smcv!n=smcv@figment.pseudorandom.co.uk: +er, the closest achievable presence
13-08-2009 17:10:20 > andrunko: to me setting a requested presence to something not supported should just fail, but we would have other problems with that
13-08-2009 17:10:32 < smcv!n=smcv@figment.pseudorandom.co.uk: +no
13-08-2009 17:10:54 < smcv!n=smcv@figment.pseudorandom.co.uk: +while offline, we can't have Set("RequestedPresence", AVAILABLE) not return until the account goes online
13-08-2009 17:11:07 < smcv!n=smcv@figment.pseudorandom.co.uk: +it can take indefinitely long
13-08-2009 17:11:28 > andrunko: true
13-08-2009 17:11:50 < smcv!n=smcv@figment.pseudorandom.co.uk: +(which is also the problem with having a RequestPresence method)
13-08-2009 17:12:17 < smcv!n=smcv@figment.pseudorandom.co.uk: +removing the check you mentioned is insufficient, because MC also suppresses redundant outgoing signals
13-08-2009 17:12:20 > andrunko: the main problem is that on plasma we can have several plasmoids showing the presence, and if we don't know if it failed or not, we may show different presence for the same account on different plasmoids :S
13-08-2009 17:12:45 > andrunko: user selected invisible on combo, he needs to know it failed, some way
13-08-2009 17:12:53 < smcv!n=smcv@figment.pseudorandom.co.uk: +if you conflate the requested presence and the current presence, then tbh you have already lost
13-08-2009 17:13:01 < smcv!n=smcv@figment.pseudorandom.co.uk: +I quite like Maemo's UI for it
13-08-2009 17:13:01 < abner!n=Abner@jalfrezi.collabora.co.uk: +andrunko, it's not just on plasma.. it will happen in multi clients
13-08-2009 17:13:10 < smcv!n=smcv@figment.pseudorandom.co.uk: +(flash the presence bubble between the desired and current presence)
13-08-2009 17:13:23 < smcv!n=smcv@figment.pseudorandom.co.uk: +but that has the same problem of "how do you know it's happened?"
13-08-2009 17:13:43 < smcv!n=smcv@figment.pseudorandom.co.uk: +or rather "how do you know when to give up?"
13-08-2009 17:14:27 > andrunko: will the request get back to busy when the user tries to set invisible and the CM goes busy?
13-08-2009 17:14:30 < smcv!n=smcv@figment.pseudorandom.co.uk: +perhaps RequestPresence(u, s, s) -> u, s, s is the only solution
13-08-2009 17:14:34 < smcv!n=smcv@figment.pseudorandom.co.uk: +andrunko: not currently
13-08-2009 17:14:46 > andrunko: that would be a solution
13-08-2009 17:15:00 < smcv!n=smcv@figment.pseudorandom.co.uk: +andrunko: conceptually: "no, because Busy was never requested"
13-08-2009 17:15:14 < smcv!n=smcv@figment.pseudorandom.co.uk: +but that would indeed be *a* solution
13-08-2009 17:15:21 > andrunko: yep
13-08-2009 17:15:27 < smcv!n=smcv@figment.pseudorandom.co.uk: +you stop flashing when RP and CP have converged
13-08-2009 17:15:29 < smcv!n=smcv@figment.pseudorandom.co.uk: +(in either direction)
13-08-2009 17:15:38 > andrunko: there is no good solution for this that I can think of
13-08-2009 17:15:46 < smcv!n=smcv@figment.pseudorandom.co.uk: +it can go on my 17 mile long list of things to solve immediately
13-08-2009 17:15:57 < smcv!n=smcv@figment.pseudorandom.co.uk: +(i.e. immediately is unlikely)
13-08-2009 17:16:17 > andrunko: nah np, just trying to figure out a temp solution
13-08-2009 17:16:23 > andrunko: and it seems there is none for now
13-08-2009 17:18:06 > andrunko: a signal RequestedPresenceSetFailed signal would also work
13-08-2009 17:18:09 > andrunko: or something like this
13-08-2009 17:18:21 > andrunko: so the UI catch it and get back to current presence
13-08-2009 17:18:58 < smcv!n=smcv@figment.pseudorandom.co.uk: +tbh I think the UI should always show your current presence
13-08-2009 17:19:10 < smcv!n=smcv@figment.pseudorandom.co.uk: +and optionally also "where you're trying to go"
13-08-2009 17:19:22 > andrunko: smcv, indeed, but if the user selected invisible in a  combo you can't just go to busy
13-08-2009 17:19:28 < smcv!n=smcv@figment.pseudorandom.co.uk: +but in any case, always "where you are"
13-08-2009 17:19:32 > andrunko: you need to inform either that the presence is about to change
13-08-2009 17:19:36 > andrunko: or let it invisible
13-08-2009 17:20:09 < smcv!n=smcv@figment.pseudorandom.co.uk: +if you're claiming in your UI that the user's presence is the requested presence, then you are lying
13-08-2009 17:20:24 < smcv!n=smcv@figment.pseudorandom.co.uk: +the user's presence is always the current presence
13-08-2009 17:20:33 < smcv!n=smcv@figment.pseudorandom.co.uk: +the presence you're trying to achieve is secondary
13-08-2009 17:20:51 > andrunko: all UIs that I know let a user select a possible presence, you can't change a combo selection by the time the user selected it, just because you don't know if it will work
13-08-2009 17:20:52 < smcv!n=smcv@figment.pseudorandom.co.uk: +I agree that supporting a Maemo-like "flash between current and requested" is valuable and needs more API
13-08-2009 17:21:03 > andrunko: the user selected "X" it should show X as selected
13-08-2009 17:21:07 > andrunko: and change to Y if it failed