jpochyla
Separate QueueBehavior into ShuffleBehavior and LoopBehavior
This PR aims to separate the QueueBehavior into ShuffleBehavior and LoopBehavior, so we are not limited to 4 pre-defined queue states.
The inspiration for this is that I always listen to my playlists in shuffle with repeat on, and this app wasn't allowing me to.
To accomplish this, an extra button was added to the UI and, in the code, QueueBehavior was turned into ShuffleBehavior and LoopBehavior. The new PLAY_LOOP_NONE SvgIcon is just a version of the PLAY_LOOP_ALL icon edited by ChatGPT, a more proper icon should probably be added.
One drawback I found is that the app crashes when trying to load a config file written before these changes, but honestly I don't know what the ideal fix (both in clean solution and respecting the app philosophy) would be, so I'll leave that up to the main faces behind the project.
Made in collaboration with @JOSEALM3IDA.
Thanks for the contribution!
Just for reference for others, this PR adds another icon to the toolbar.
I have a few concerns with this, but they mostly stem from visual clutter. I think part of the ethos of this application is to be quite minimal, functional and condensed as possible (in contrast to the 1st party app).
My suggestion, could we perhaps make the shuffle icon right clickable that would then allow the loop function (which I believe might be less commonly used) to be toggle-able on right click?
Also at smaller widths we have a visual glitch - I just think adding another icon might not be tenable here - even the lyrics icon is maybe too much as it is now.
Thanks for the feedback!
I understand your concern of UI clutter, as I myself feel like minimalist but useful UIs are way better. My only concern with your right-click approach is how to give the user proper feedback about which option is currently being used. If it's hidden behind a right-click, although technically functional and visually pleasing, it's not the best UX.
One thing I could think of is having the icons stacked. That would fix the visual glitch at smaller widths, but I guess it would keep cluttering the UI. Although the UX benefits are clear imho.
(please ignore the glitch on the circle.plus button)
Do you still believe that going with the right-click is the way or do you think theres some merit to the stacked icons? If we're going right-click, what do you think is the best approach to give the user proper feedback about which option they chose for the looping?
Personally, I think having a right click menu on top of the current functionality makes the most sense. It can then also have a switch to all the other options too!
Edit: This can be as simple as the different options being displayed then the player switching to that place in the cycle if that makes sense.
Just out of curiosity, how does Spotify do this? Whats the visual mechanism to describe these shuffle x loop states?
I share the worry that the UX might be affected by hiding it under a right click menu.
Particularly, I think we would need to change all the icons and/or create new icons here, so that both "loop" and "shuffle" states are visible without accessing the menu, if we really want to follow this route.
Having to open a menu to view something that should be "at a glance" feels like bad UI/UX, but for changing the state/behavior, it's okay. Inevitably this means the UI, or at least this specific icon set, becomes slightly more cluttered. I think that's a good enough tradeoff
Perhaps then a solution to it getting too cluttered would be when the window size becomes smaller we revert back to the original collapsed icon?
Then when it's larger we split them into two?
If by "original" you mean the one before this PR, then that's also not very good because you lose functionality (which is what this PR is trying to add so that it matches the original Spotify client). If you mean the right click menu idea, then I would tend to agree
Yeah sure the one with the right click menu but also having the clicking functionality of before if that makes sense?
I tried implementing the menu but couldn't figure it out in a way that made sense to me. I had a menu working once, but because of the way the UI lib treats them, the rest of the UI would stay frozen while the menu was open, and that (in my opinion) is a huge no.
As you can guess I'd be more than thrilled to see this PR getting merged, but I understand your concerns. In one of my last commits I did fix the overlapping issue with the downside that the app is now less shrunk-able.
How do we proceed?