Review Request 118045: Use requestedPresence throughtout

[James Smith]

> On May 8, 2014, 10:23 a.m., James Smith wrote:
> > There was a problem IIRC with the signal form of onRequestedPresenceChanged() not the m_globalPresence->requestedPresence(). The onRequestedPresenceChanged() signal doesn't set the presence properly when accounts are disabled in the accounts kcm. Couldn't using m_globalPresence->requestedPresence() cause problems when the requestedPresence() isn't actually what the account is set to? For instance, now, when the currentPresence() is Away and the account presence is Away, the plugin won't activate. If the requestedPresence() was at Not Available and the account moved to its best presence Away, the plugin will activate. So, that's probably an improvement. Do you know why Away was filtered as an originating presence? This doesn't work for the status message plugins because the autoaway plugin doesn't overwrite the status message with the preset away message (if there is one set), and only doesn't overwrite the status message with the preset away message (if there is one set) for Away -only-, as the originating presence.
> 
> David Edmundson wrote:
>     >onRequestedPresenceChanged() signal doesn't set the presence properly when accounts are disabled in the accounts kcm
>     
>     onRequestedPresenceChanged is a slot. I'm confused what you mean.
>     
>     If an accunt is disabled doing requestPresence won't do anything.
>     
>     >Do you know why Away was filtered as an originating presence? 
>     
>     If you're already away there's no point setting yourself to away again. More importantly you don't want to leave being in away when you autoaway gets deactivated.
> 
> David Edmundson wrote:
>     *account

currentPresenceChanged() signal. I think the contact list currently connects to it and every other place the presence is needed requestedPresence() is used. Using requestedPresenceChanged() has issues when disabling accounts where when reenabling and showing enabled in the kcm the status doesn't actually get set at what it's supposed to in the presence chooser and / or the presence app, instead staying offline.

>If you're already away there's no point setting yourself to away again

It should actually be required, to set the status message if there's a custom status message. Otherwise the set message isn't picked up, and the plugin doesn't go to away with message, or continue to not available. Even if left empty, the away / N/A messages don't get changed to the active status message plugin. So I think that's currently a fixme. Leaving AutoAway should restore the last presence, whether it was away or not. We have enough problems in the contact list with that signal triggering on status message plugins disabling, it also doubtlessly works to set the presence back to what it was prior to the plugin engaging whether it was also away or not.


- James


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/118045/#review57555
-----------------------------------------------------------


On May 7, 2014, 10:29 p.m., David Edmundson wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/118045/
> -----------------------------------------------------------
> 
> (Updated May 7, 2014, 10:29 p.m.)
> 
> 
> Review request for Telepathy.
> 
> 
> Repository: ktp-kded-module
> 
> 
> Description
> -------
> 
> Use requestedPresence throughtout
> 
> Mixing current + requested will also get you in a mess as things will
> often be slightly out for a while.
> 
> 
> Diffs
> -----
> 
>   status-handler.cpp 4b9c25a 
>   autoaway.cpp 13b71a5 
> 
> Diff: https://git.reviewboard.kde.org/r/118045/diff/
> 
> 
> Testing
> -------
> 
> 
> Thanks,
> 
> David Edmundson
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-telepathy/attachments/20140509/8d7ed9a6/attachment.html>