GNOME Bugzilla – Bug 777041
Unexpected behaviour of playlist notification actions, sometimes deletes, sometimes not
Last modified: 2017-03-13 21:30:09 UTC
Unexpected behaviour of playlist notification X action, sometimes deletes, sometimes not Reproduce: delete playlist 1 - wait for 5 seconds (really_delete* becomes false) delete playlist 2 - press X on notification (really_delete* is still false so no deletion) playlist disappears from side bar -- **so I assume deletion was necessary** run gnome-music again and playlist 2 appears again *really_delete is a member of playlistview.py file Expected: > X button always deletes the playlist & undo always prevents deletion of the playlist
Created attachment 343148 [details] [review] Made the playlist notification X action independent.
Comment on attachment 343148 [details] [review] Made the playlist notification X action independent. really_delete was complicating action's behaviour. It is more predictable now. I have assumed that X should always delete the playlist, because I observed that X deletes the playlist from the sideview always. Hence, now it should delete the playlist always and it would not appear when restarting the application.
Nice catch. I'm sort of wondering why we have a close button at all, they're all timed. It seems unnecessary to me.
I agree, 5 seconds are not long enough that user might want to close it intentionally. Should I remove the close button and make a patch?
A patch would be appreciated. For the loading notification as well if you have the time.
Created attachment 343191 [details] [review] Simplified playlist and loading notifications. Removed close buttons from these notifications, and removed really_delete which was unnecessarily complicating behaviour.
Review of attachment 343191 [details] [review]: lgtm but I want to discuss with the designers a bit further before push
Thanks for the patch.