Rethink Playlists Views and Logics and implement smart playlist operations
Current situation and limitations
There are four kinds of playlists:
- smart playlists: they are automatically created and handled by tracker. They reflect the listening habits of the user (most played song, never played, etc.)
- user playlists: created by the user from the ui
- on-disk playlists: playlists from cue/m3u files. Their support has been removed because it was somewhat buggy. they appeared as unnamed. They were editable but there was no write-back.
- grilo source playlists: they are retrieved from a grilo source. Not handled now. Grilo integration in Music needs some attention and rework.
|smart playlist||user playlist||on-disk||grilo source|
|handled by Music||yes||yes||no||no|
|edition||automatic||user from ui||no||no|
|removed by a tracker reset||yes||yes||no||no|
Support and interaction with the player are in a good shape. It supports the following operations:
- create a playlist
- remove a playlist
- add song(s)
- remove song(s)
- dnd operation
They work but their integration with the player is broken. No per song operation. One can only refresh the whole playlist each time a new song is played.
It's impossible to know precisely which content of a Smart Playlist changed. For example, if the playing song from a Smart playlist is removed, one cannot correctly update the
user and smart playlists workflow
There are two different codebases and logics to update playlists:
- user playlists work on song operations (added, removed, position changed)
- smart playlists need to be completely refreshed even if only one song changed
A possible solution would be to adapt the user logic to smart playlists. One would need to get the following information from a smart playlist: song added, song removed, position changed.
Playlists logic is supposed to be handled by
playlists.py. It needs to be rewritten. There is also some logic inside
playlistview.py. It should not be there.
@feaneron has already worked on a rewrite of
playlists.pyto provide a self contained model. See branch
wip/gbsneto/contained-playlistsand this blog post
- There is an existing mockup to refresh
PlaylistView. See #49
@carlosg has some ideas on how to improve Tracker + Smart Playlists interaction.
The main idea would be to be notified on a Smart Playlist change and to get only the modifications:
GraphUpdatedwill inform of the specific
nfo:hasMediaFileListEntryproperty change (maybe too complicated for our use case)
- shortcircuit the changes directly into Music
extend smart playlists capabilities (smarter playlists)
Music only handles five Smart Playlists:
- most played
- never played
- recently played
- recently added
- decide if we want to interact with on-disk playlists
- figure out how to deal with grilo playlist
- decide on tracker + Smart Playlists logic
- define a design to integrate "smarter playlists"
- update the mockups from #49 with the previous decisions made
- update playlists.py based on feaneron branch
- update tracker logic
- implement an updated #49
- implement "smarter playlists"
- implement grilo changes if necessary
high resolution mockup