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

[James Smith]

> On March 12, 2014, 2:10 p.m., David Edmundson wrote:
> > global-presence-chooser.cpp, line 357
> > <https://git.reviewboard.kde.org/r/116748/diff/2/?file=253427#file253427line357>
> >
> >     So we clear out the presence just before we activate now playing.
> >     
> >     I can see two main problems:
> >     
> >     1) the kded won't be able to restore the statusMessage when you deactivate
> >     
> >     2) you're now in a race between us messaging the kded to start the now playing, and us telling each CM to change state and the kded monitoring that.
> >     
> >     I can only imagine this making things even messier as we'll end up going
> >     
> >     contact list -> kded: activateNowPlaying
> >     
> >     kded -> CM: setStatusMessageTo("Now Listening to...")
> >     
> >     contact list -> CM: setStatusMessage("")
> >     
> >     CM -> KDED: I've changed presenceMessage!
> >     
> >     I think if KDED is working as designed it would then disable the nowPlaying..
> >     
> >     Either way: we're in a set of races trying to set the message to multiple things at once. 
> >

I don't think this is much of an issue with both presence changers (applet and chooser) having been designed such that the presences are fairly close to hard-coded as far as the application is concerned. ie. Every status message is pretty well settable from the other irregardless of which presence + status message was just set. nowPlaying shouldn't be above a custom presence + status message pairing. Re-entering a custom status message state is manually accomplished instead because kded sees that nowPlaying is just filling another slot that must neccessary be initially empty, just like the model expects from nowPlaying, where the presence is a variable constant which the status message isn't tied to.
 
Ideally disabling the nowPlaying plugin works from 
a) a single application, with no option but to put the configuration in the most user-friendly place possible.
b) possibly is configured -only- in the systemsettings and enabled / disabled by kconfig from elsewhere in a single user-facing place.

I don't necessarily prefer disabling plugins in the kded automatically, but I think that a clean and consistently interacting set of agents and applications should take individual care of cleanup of configured status plugins on presence change instead.


- James


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


On March 12, 2014, 6:50 a.m., James Smith wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/116748/
> -----------------------------------------------------------
> 
> (Updated March 12, 2014, 6:50 a.m.)
> 
> 
> Review request for Telepathy.
> 
> 
> 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/20140313/73f6cd65/attachment.html>