miscellaneous improvements to queue looping

1 files changed, 41 insertions, 0 deletions

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: <downloaderArg>" 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?