Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Hey,
so the motivation for this feature is that adding songs to play next breaks when you are on shuffle. Spotify solves this with a "second queue" which is immune to shuffle. However, going for less complexity, I have implemented a feature I knew from foobar2000: The ability to randomize the queue, that means, shuffling the elements of the backing queue Vec.
I tested the feature on my system in both debug and release mode. It seems to work.
Design choices:
ncspot
is playing when you execute the command, astop()
is executed and playback is restarted from the top of the queue as soon as randomizing is completed. Alternatives would have been to keep the current song playing, and either move it to the start, keep its position fixed or update the internal playback state, as after randomization the GUI was showing the title of the song which then occupied the sameid
. But stopping playback (and restarting after) seemed like the simplest, cleanest case.Shuffle
mode gets deactivated when you randomize. My view is that the two features combined wouldn't make much sense.TODO
mpris
When I naively added the code in mpris.rs (which is now commented out), I got a lot of incomprehensive compiler errors, probably caused by complex macro expansion. One hypothesis of mine is that properties which have neither parameters nor return values are not supported. Since I have almost no experience with DBus I hope you can help me here @hrkfdn (or someone else ofc).
I don't know how much work that would be, and would probably be in favor of first accepting this PR and making a new one for that extra feature. But the odds of me finding time for that aren't too bad :)
@hrkfdn, would you be, in principal, willing to merge the feature described in this PR, and are there any changes needed for new commands I have overlooked? I just grep'd for
shuffle
and modified the same places (where it made sense).EDIT: Maybe this even helps with #1075 since randomization is correctly shown and doesn't add any complexity. I want to stress again that foobar2000 which I used for a long time had both features, and both were useful in its own.