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

[bugzilla-daemon at freedesktop.org]

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

--- Comment #12 from Simon McVittie <simon.mcvittie at collabora.co.uk> 2010-05-06 02:58:08 PDT ---
Specification
=============

> +        <p>This property indicates whether the account's
> +          <tp:member-ref>Connection</tp:member-ref> is changing presence</p>

I preferred my version: "If true, a change to the presence of this account is
in progress."

> +
> +        <tp:rationale>
> +          <p>Use cases:</p>
> +
> +          <ul>
> +            <li>user has two applets (one in the desktop area and another
> +             one in the system tray area) showing the current presence.
> +             User tries to change the presence and ChangingPresence changes > to
> +             true. Now both applets start to blink. After the presence is set,
> +             ChangingPresence changes to false and both applets now show the
> +             <tp:member-ref>CurrentPresence</tp:member-ref>.</li>
> +          </ul>
> +        </tp:rationale>

That's only one use case, so it doesn't really need to be in a list :-)

I'd be inclined to move this to the end of the docstring so the whole
description of how the property works comes first, and shorten it to something
like:

    <tp:rationale>
      <p>This allows UIs to indicate that a presence change is in progress
        or has finished, even if the change was initiated by a different
        UI.</p>

      <p>For instance, Maemo 5 and Empathy indicate a presence change by
        having the presence indicator alternate between the RequestedPresence
        and the CurrentPresence; they should start blinking when
        ChangingPresence becomes true, and stop when it becomes false.</p>
    </tp:rationale>

> +        <p>The AccountManager MUST set this property to true whenever a change
> +        in the account's <tp:member-ref>Connection</tp:member-ref> presence is
> +        requested. When the change is finished, either successfully or with an
> +        error, this property MUST be set to false.</p>
> +      </tp:docstring>

I preferred my version, which makes it explicit how things should combine into
AccountPropertyChanged signals:

    Whenever _RequestedPresence_ is set on an account that could
    go online, or whenever an account with a non-offline
    _RequestedPresence_ becomes able to go online (for instance
    because _Enabled_ or _Valid_ changes to True), ChangingPresence MUST
    change to True, and the two property changes MUST be emitted in the same
    _AccountPropertyChanged_ signal, before the Set method returns.

    When the account manager succeeds or fails in changing the presence,
    or the connection disconnects due to an error, ChangingPresence MUST
    change to False as part of the same _AccountPropertyChanged_ signal.

Mission Control
===============

The MC branch looks good now, but please don't merge it just yet - I'd much
rather do a spec release with this change included, get that into
telepathy-glib, and get MC depending on that telepathy-glib.

telepathy-qt4
=============

> + * \fn void Account::isChangingPresence(bool value);

I think you mean changingPresence(bool).

Other than that, it looks OK, conditional on updating telepathy-qt4 to a spec
release that includes this property.

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