[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 #13 from Andre Moreira Magalhaes <andrunko at gmail.com> 2010-05-07 06:44:06 PDT ---
(In reply to comment #12)
> 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."
Done

> > +
> > +        <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>
Done

> > +        <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.
> 
Done

> 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.
Great, tnx

> telepathy-qt4
> =============
> 
> > + * \fn void Account::isChangingPresence(bool value);
> 
> I think you mean changingPresence(bool).
I Used isChangingPresence cause we use isSomething for other boolean accessors,
as in isValid/isEnabled/... but I can change it if you prefer.

> Other than that, it looks OK, conditional on updating telepathy-qt4 to a spec
> release that includes this property.
Yep, tp-qt4 will only include this when we update the spec, it's just that I
already implemented it so I could test it easily.

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