Rethink Playlists Views and Logics and implement smart playlist operations
Current situation and limitations
different playlists
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 |
user playlists
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
smart playlists
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 PlaylistView
.
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.
playlist logic
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.
Solution
previous work
-
@feaneron has already worked on a rewrite of
playlists.py
to provide a self contained model. See branchwip/gbsneto/contained-playlists
and this blog post - There is an existing mockup to refresh
PlaylistView
. See #49
tracker interactions
@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:
- ̀
GraphUpdated
will inform of the specificnfo:hasMediaFileListEntry
property change (maybe too complicated for our use case) TrackerNotifier
- 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
- favorites
@aday proposed to extend smart playlists to handle much more. See this article part "Event smarter playlists"
to do
- 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
Mockups
initial wireframe
high resolution mockup