Review Request 116748: State-affinity custom status message <-> nowPlaying plugin bug

[James Smith]

> On March 12, 2014, 2:16 p.m., David Edmundson wrote:
> > "Fixes a state affinity issue where the contact list won't recognise a nowplaying plugin enable event when there is a custom status message set."
> > 
> > Can you explain why it won't be recognised? It will help me understand this patch.
> 
> James Smith wrote:
>     The current ordering of presences (as many as I can remember) in the kded plugin is as follows:
>     
>     b) plugin presences (w/ attached status messages)
>     c) user-set presences
>     
>     b) plugin presences (w/ attached status messages)
>     d) custom status message plugins
>     
>     c) user-set presences
>     d) custom status message plugins
>     
>     a) plugin presences
>     c) user-set presences
>     
>     d) custom status message plugins
>     a) plugin presences
> 
> David Edmundson wrote:
>     Then should the fix not be in this kded ordering?
> 
> David Edmundson wrote:
>     Especially as it looks like this was introduced by your last patch.
> 
> James Smith wrote:
>     It's probably easier to get right in the contact list, which currently additionally has hard to reproduce affinity glitches. The presence applet has to be taken into account, because someone can change to a custom status not knowing that the next track change in nowPlaying will necessarily overwrite the user-set presence. Also the advantages of the current code, such as leaving the status messages blank in the presence plugins to have the dynamic nowPlaying status message sticky when gone away / extended away are hard to re-implement. 
>     
>     https://git.reviewboard.kde.org/r/115425/ and this review are probably semi-related in scope.
>     
>     Is there a clean way to turn off nowPlaying and restore the original status message?
> 
> Martin Klapetek wrote:
>     > someone can change to a custom status not knowing that the next track change in nowPlaying will necessarily overwrite the user-set presence
>     
>     Which is why the nowplaying should be automatically disabled when that happens; if user knowingly changes his presence to anything he had configured before, he know he wants to have that presence now, therefore the nowplaying should just disable itself and not overwrite the presence anymore.

contact list -> kded: activateNowPlaying

kded -> CM: setStatusMessageTo("Now Listening to...")

contact list -> CM: setStatusMessage("")

CM -> KDED: I've changed presenceMessage!
could look like
CM -> KDED: I've cornered a status presence!

We don't save the (previous) custom presence message this way and I think it's probably the only drawback and one of the reasons I'd prefer to have a sorry dialog to keep the user from unknowingly ignoring the pitfalls of haphazardly engaging the nowPlaying from a custom presence and expecting that presence status message to backdrop in case any stoppages happen. Then it's a two-step manual process to switch to the nowPlaying presence but given the technical differences and the ambiguity in the expected behaviour when stopping the nowPlaying it's best to not engage nowPlaying from one of the custom messages and instead count automatic presence awareness and modification execution as a complicated (future) feature. This way the only presence auto-saved is de-facto empty when a status message plugin is active, avoiding situations where the user has activated a status message plugin and then changed the presence in the presence applet, or attempted to overwrite the status message output with a custom message. In these situations the status is not properly saved to disk for retrieval because 1) it is set to what it was before and custom status messages are ignored 2) or an active status message plugin is engaged ruling out saving to disk despite the custom status message remaining in effect.


- James


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


On March 15, 2014, 4:14 a.m., James Smith wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/116748/
> -----------------------------------------------------------
> 
> (Updated March 15, 2014, 4:14 a.m.)
> 
> 
> Review request for Telepathy.
> 
> 
> Bugs: 332082
>     http://bugs.kde.org/show_bug.cgi?id=332082
> 
> 
> Repository: ktp-contact-list
> 
> 
> Description
> -------
> 
> Fixes a state affinity issue where the contact list won't recognise a nowplaying plugin enable event when there is a custom status message set.
> 
> 
> Diffs
> -----
> 
>   global-presence-chooser.cpp 2047473 
> 
> Diff: https://git.reviewboard.kde.org/r/116748/diff/
> 
> 
> Testing
> -------
> 
> Compile, run-check.
> 
> 
> Thanks,
> 
> James Smith
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-telepathy/attachments/20140315/47b2b2b6/attachment.html>