Closed ksiazkowicz closed 5 years ago
Hi!. Look great. Some questions:
I did not test or build this. Please just merge it and we will see.
1). I think it is a bug in the silica code. After dragging they assign something to 'value' which will lose the link that has been set in our qml. 3.) a playlists has snapshots. every modification (add/delete/reorder) will create a new snapshot of the playlist. if a playlist is modified while being played the old snapshot will keep on being played.
1) Oh, right, I haven't noticed that bug, right. 3) I understand, that a call to api.spotify.com/v1/playlists/playlist_id would return a latest snapshot of the playlist with given ID, right? It has information about what tracks are on this playlist, images etc. and also a snapshot_id. If you make a change to a playlist, the ID is the same (meaning, context doesn't change), just snapshot_id value probably changes to something else. The only issue that I see here is that contextDetails would hold an outdated list of tracks, since it only compares IDs.
Suppose you added a track. It will not be played since the new track is not part of the old snapshot (which is being played). I have this issue in two situations:
But lets work on this after you merged this pr. Do I have to agree/+/lgtm or whatever?
Moved most of the logic for managing playbackState, controlling playback and MPRIS stuff to SpotifyController component.
The idea is to unclutter hutspot.qml and make it easier to maintain only one, up to date copy of playbackState, instead of having the same code repeated in both hutspot.qml and on Playing.qml page.
@wdehoog please let me know if I didn't break any feature, I'm not familiar with your most recent changes.