Rather than iterating over the entire playlist ourselves, we can instead
use the g_queue_remove_all() function to do most of the work for us and
then send an appropriate number of "removed" callbacks.
Signed-off-by: Anna Schumaker <Anna@NoWheyCreamery.com>
This function simply triggers the "updated" callback for the given
playlist and track. I updated the gui model to handle taking tracks
instead of row indexes, since this lets me reuse the same for-each
function that we do for sorting. Additionally, this prevents UI updates
for playlists that aren't currently visible.
Signed-off-by: Anna Schumaker <Anna@NoWheyCreamery.com>
I move the random variable into the playlist code since it is no longer
used by the queue layer. This gives me the opportunity to change it
into a boolean rather than a bit flag.
Signed-off-by: Anna Schumaker <Anna@NoWheyCreamery.com>
Let's have the playlist generic functions pick the next track rather
than redirecting to the queue code.
Signed-off-by: Anna Schumaker <Anna@NoWheyCreamery.com>
In most cases this function just triggers a UI update, but system
playlists have a little extra bookkeeping to do to remove the track from
the Queued Tracks playlist.
Signed-off-by: Anna Schumaker <Anna@NoWheyCreamery.com>
This function is called to force-sort the playlist. Additionally, we
trigger the "playlist-sorted" callback to to notify the gui that
playlist rows need to be updated.
Additionally, I implement the gui_model_update_all() function to loop
over the model and update all rows of the current playlist.
Signed-off-by: Anna Schumaker <Anna@NoWheyCreamery.com>
This replaces the "reset" field that had been passed to sort. I think
this makes things a little more straightforward, and gives us a function
we can call when freeing playlists.
Signed-off-by: Anna Schumaker <Anna@NoWheyCreamery.com>
This function uses the playlist save flags enum to determine what
exactly to save, including support for backwards compatibility with
6.4.x playlists.
Signed-off-by: Anna Schumaker <Anna@NoWheyCreamery.com>
This function uses the playlist save flags enum to determine what
exactly to load, including support for backwards compatibility with
6.4.x playlists.
Signed-off-by: Anna Schumaker <Anna@NoWheyCreamery.com>
And stores it for future reference, so we don't have to keep looking up
current and previous playlists.
Signed-off-by: Anna Schumaker <Anna@NoWheyCreamery.com>
This is much more straightforward than converting an id to a name and
then looking up playlists from there. This patch removes the now-unused
playlist_get_name() function.
This patch also lets me simplify the system playlist unit test, since I
can now check several similar operations using a loop. Additionally, I
change calls to pl_system_lookup() into pl_system_get() for efficiency.
Signed-off-by: Anna Schumaker <Anna@NoWheyCreamery.com>
I think "lookup" is a better name for this function, since it's similar
to performing a dictionary lookup.
Signed-off-by: Anna Schumaker <Anna@NoWheyCreamery.com>
Additionally, it also uses a playlist-level function pointer to decide
what to do. In most cases this calls the generic sort function, but the
history playlist should never be sorted.
Signed-off-by: Anna Schumaker <Anna@NoWheyCreamery.com>
Additionally, playlist_set_random() uses a playlist-level function
pointer to decide what to do. In most cases this will simply toggle the
flag, but the history playlist does not support random playback.
Signed-off-by: Anna Schumaker <Anna@NoWheyCreamery.com>
Rather than going through playlist-type operations. Additionally, I
take this opportunity to change playlist_remove() to take a playlist
struct directly.
Signed-off-by: Anna Schumaker <Anna@NoWheyCreamery.com>
Rather than going through playlist-type operations. Additionally, I
take this opportunity to change playlist_add() to take a playlist struct
directly.
Signed-off-by: Anna Schumaker <Anna@NoWheyCreamery.com>
Rather than going through the playlist-type operations. Additionally, I
take this opportunity to change playlist_delete() to take a playlist
struct directly.
Signed-off-by: Anna Schumaker <Anna@NoWheyCreamery.com>
This is much more useful than a boolean status, since we can use the
playlist pointer right away.
Signed-off-by: Anna Schumaker <Anna@NoWheyCreamery.com>
The playlist code is heavily tested by unit tests for the files in
core/playlists/, so we no longer need to have a separate playlist test.
Signed-off-by: Anna Schumaker <Anna@OcarinaProject.net>
I'm going to use this to distinguish between various playlist types that
are about to be added. Let's update the playlist functions first, and
then add more types in a future patch.
Signed-off-by: Anna Schumaker <Anna@OcarinaProject.net>
The thread pool is used to fetch album art in the background, but this
can slow down most tests that aren't interested in album art. Adding a
(testing-only) function for running without the thread pool speeds
things up a bit.
Signed-off-by: Anna Schumaker <Anna@NoWheyCreamery.com>
The track database now tallys total play count and unplayed track count,
so we can use this information for calculating averages. I also changed
the least played tracks playlist to allow tracks with play count equal
to the average.
Signed-off-by: Anna Schumaker <Anna@OcarinaProject.net>
"Banning" a track is a bit harsh. Let's talking about hiding tracks
instead, so that it sounds friendlier.
Signed-off-by: Anna Schumaker <Anna@OcarinaProject.net>
I think it makes more sense to have the collection manage if banned
tracks are displayed or not, rather than doing this from the playlist
layer.
Signed-off-by: Anna Schumaker <Anna@OcarinaProject.net>
There is at least one place in the gui where it needs to know if a track
was actually added to a playlist. Adding a return value is the best way
to know what happened.
Signed-off-by: Anna Schumaker <Anna@OcarinaProject.net>