[Bug 26752] New: Setting a not supported presence state to a telepathy account does not deliver any failing feedback

[bugzilla-daemon at freedesktop.org]

http://bugs.freedesktop.org/show_bug.cgi?id=26752

           Summary: Setting a not supported presence state to a telepathy
                    account does not deliver any failing feedback
           Product: Telepathy
           Version: unspecified
          Platform: Other
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: medium
         Component: libtelepathy
        AssignedTo: telepathy-bugs at lists.freedesktop.org
        ReportedBy: jan.oelze at basyskom.de


SOFTWARE VERSION:
libtelepathy-qt4-0    0.2.0


PRECONDITIONS: 
TP Account is setup and functional but not connected

STEPS LEADING TO PROBLEM: 
1. the account gets connected using setRequestedPresence(...) using a supported
online state ( e.g. online )
2. change the presence to a state that is not supported for the used account (
maybe extended away )

EXPECTED OUTCOME:
either the signal currentPresenceChanged gets emitted with the state was taken
instead of the wanted one
or
additional signal about failing in setting the desired presence

ACTUAL OUTCOME:
no signal regarding the current presence is emitted

FREQUENCY OF OCCURRENCE: 
always


Additional Chatlog regarding this issue:

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 at figment.pseudorandom.co.uk: +andrunko: the
current presence never changed
13-08-2009 17:08:05 < smcv!n=smcv at 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 at 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 at figment.pseudorandom.co.uk: +perhaps Account
needs a RequestPresence method, that returns what actually happened
13-08-2009 17:09:03 < smcv!n=smcv at figment.pseudorandom.co.uk: +file a bug
13-08-2009 17:09:07 > andrunko: ok
13-08-2009 17:09:17 < smcv!n=smcv at figment.pseudorandom.co.uk: +(callers would
need to set a ~infinite timeout, though)
13-08-2009 17:09:42 < smcv!n=smcv at 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 at 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 at figment.pseudorandom.co.uk: +no
13-08-2009 17:10:54 < smcv!n=smcv at 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 at 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 at figment.pseudorandom.co.uk: +(which is also
the problem with having a RequestPresence method)
13-08-2009 17:12:17 < smcv!n=smcv at 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 at 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 at figment.pseudorandom.co.uk: +I quite like
Maemo's UI for it
13-08-2009 17:13:01 < abner!n=Abner at 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 at figment.pseudorandom.co.uk: +(flash the
presence bubble between the desired and current presence)
13-08-2009 17:13:23 < smcv!n=smcv at 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 at 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 at 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 at 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 at figment.pseudorandom.co.uk: +andrunko:
conceptually: "no, because Busy was never requested"
13-08-2009 17:15:14 < smcv!n=smcv at 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 at figment.pseudorandom.co.uk: +you stop
flashing when RP and CP have converged
13-08-2009 17:15:29 < smcv!n=smcv at 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 at 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 at 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 at figment.pseudorandom.co.uk: +tbh I think the
UI should always show your current presence
13-08-2009 17:19:10 < smcv!n=smcv at 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 at 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 at 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 at figment.pseudorandom.co.uk: +the user's
presence is always the current presence
13-08-2009 17:20:33 < smcv!n=smcv at 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 at 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


-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.