Emit Player::SetQueue event

[ralph]

What does this do?

This emits a new universal Player::SetQueue event.

Background info: How is the Spotify Connect queue organised?

The Spotify connect queue basically has the following data structure:

context_uri: SpotifyUri
current_track: Track
prev_tracks: []Track
next_tracks: []Track

Each Track has at least a track URI and a provider which can be autoplay, context, queue or unavailable.

• autoplay: Added by Spotify to keep playing
• context: part of the current context identified by context_uri
• queue: manually queued while a context was loaded
• unavailable: self explanatory

Why is this event "universal"?

There are multiple actions that manipulate the queue in different ways. Examples:

• Loading a new context: manipulates context_uri, current_track, prev_tracks, next_tracks
• Queuing a new track/album/playlist while a context is loaded: manipulates next_tracks
• Reordering tracks in the queue: next_tracks
• Removing tracks from the queue: next_tracks

If a GUI application wants to adjust its state when any of these actions are performed remote or local, it just needs to listen to this one universal event. The queue displayed in the GUI is always correct and always up to date.

Why does this remove AddToQueue that was just added in 87d37c3 ?

AddToQueue is a special case of SetQueue, and SetQueue covers all cases of AddToQueue usage. Also, it's less error prone for app developers. Say a GUI developer wants to display the current queue from Spirc, and the queue looks like this:

`context` Track 1 <- currently playing
`context` Track 2
`context` Track 3
`context` Track 4

When another track is queued, it will be placed after the currently playing track:

`context` Track 1 <- currently playing
`queue` Track 1
`context` Track 2
`context` Track 3
`context` Track 4

In this case, AddToQueue will be emitted for Track 1, and the GUI developer will be responsible to add it in the right position of the app's state.

When yet another track (or collection of tracks, e.g. an album with 2 tracks) is queued, those will be placed after the currently playing track AND after all the other queue tracks:

`context` Track 1 <- currently playing
`queue` Track 1
`queue` Track 2
`queue` Track 3
`context` Track 2
`context` Track 3
`context` Track 4

In this case, AddToQueue will be emitted with Track 2, then with Track 3. Again, the developer of the consuming app is responsible for placing the new tracks in the right position.

In contrast to this, SetQueue always emits the whole queue with the tracks in the right order, so the developer of the consuming app cannot place the tracks in the wrong position.

Also, AddToQueue was never in a release, so removing it is ok imho.

Are there downsides?

As we're emitting ALL THE QUEUE FIELDS \o/ with every change, we do sometimes emit more than necessary. But we have to emit next_tracks most of the time, and the remaining queue fields are not that large compared to next_tracks. current_track and context_uri is negligible, and prev_tracks is capped at 20 tracks.

How to go from here?

I'd love to hear your input on this. Do you think a universal SetQueue event is a good thing? Or would you rather have more fine grained events emitting less data, e.g. one for prev_tracks, one for next_tracks one for current_track and current_track? Or should we keep the universal SetQueue for actions that manipulate all of next_tracks, but keep AddToTrack when adding tracks to the queue, manipulating only small parts of next_tracks?

The current approach works well for me and my reactive SwiftUI app, and makes updating the queue incredibly easy. But I'm still pretty new to this and there might be use cases that I didn't think of.