From e8a55f10dd9749ad240b165e318db0a1d2f00a9a Mon Sep 17 00:00:00 2001 From: "(quasar) nebula" Date: Wed, 1 Jun 2022 23:35:03 -0300 Subject: miscellaneous improvements to queue looping --- todo.txt | 41 +++++++++++++++++++++++++++++++++++++++++ 1 file changed, 41 insertions(+) (limited to 'todo.txt') diff --git a/todo.txt b/todo.txt index a6ce5ef..b10c614 100644 --- a/todo.txt +++ b/todo.txt @@ -649,3 +649,44 @@ TODO: The "From: " text in the playback info element *does* cut TODO: "Play later" has a slight chance of keeping the track in the same place, which is accentuated when there's only a couple tracks left in the queue. + +TODO: "Loop mode" should be an option under the Queue menu, not Playback. + (Done!) + +TODO: "Loop mode" setting should be displayed in the queue's length label! + Probably on the same line as ex. "2 / 3", and only when the currently + playing track is selected. + (Done!) + +TODO: "Clear past current" and "clear up to current" should probably be visible + from the Queue menu! + +TODO: The queue length lebel is kinda busy, and doesn't fit everything so well + on thinner screens. That should get checked out! + (Done!) + +TODO: When the last track in the queue finishes playing and the queue is set to + shuffle, the currently selected index in the queue listing won't be moved + to the new first track (so, reset to zero). The cursor just ends up on + whatever track had been the last in the queue (which is obviously now in + some random location - even possibly the first track, but usually not). + I have a feeling this is the result of shuffling first - which updates + the selected index to go to wherever the last track ended up - and then + playing the first track, but not moving the cursor back to the start + because it's apparently not at the end anymore. But I could be totally + misremembering how this code works. :P --- Nope not even related LOL. + Good guess though! We don't even have to worry about that situation, with + the way selecting the new playing track works. It checks against the + track which *was* playing... but that was getting cleared to make the + shuffle work properly (applying to the whole queue instead of just the + stuff past the current track, which is nothing when you're at its end). + Now we just use a flag to ignore the current playback position. Since the + currently playing track is retained for the 'playing track' event, the + existing code does the rest of the work and selects the newly playing + track (whatever's been shuffled to the start) all on its own! + (Done!) + +TODO: Apparently pressing any key while the UI is booting up will make the + screen totally black and unresponsive (and apparently inactive) until the + screen is resized. I think we're interrupting a control sequence somehow, + and that isn't being handled very well? -- cgit 1.3.0-6-gf8a5