diff options
Diffstat (limited to 'todo.txt')
| -rw-r--r-- | todo.txt | 128 |
1 files changed, 125 insertions, 3 deletions
diff --git a/todo.txt b/todo.txt index dab8e29..da6c9e6 100644 --- a/todo.txt +++ b/todo.txt @@ -577,9 +577,6 @@ TODO: "BAM #45.3 - no" displays as "BAM #45.no" in the queue? Seems wrong! TODO: "Challenge 1 (Tricks)" etc in FP World 3 are "Challenge (Tricks)"! Bad. (Done!) -TODO: Pressing next track (shift+N) on the last track should start the first - track, if the queue is being looped. - TODO: Tabber tab list should be accessible via tab (key). TODO: Show current index and number of tabs beside tabber tab list. @@ -616,3 +613,128 @@ TODO: Show debug log messages when validating a command fails! On both server TODO: Naming a shared sources list should definitely happen in a function. (Done!) + +TODO: Pressing next track (N) on the last track should start the first track, + if the queue is being looped. + (Done!) + +TODO: Timestamp files. Oh heck yes. + (Done!) + +TODO: Show the current chunk of a track you're on according to its timestamps, + in both the queue and the main listing! (Put the playing indicator next + to both the track itself and the timestamp element.) + + Possibly tricky, but try to make this tie in with the "time since/until" + indicator thingies at the bottom of the queue listing element too! + (Done - both parts!) + +TODO: Some kind of timestamp indicator in the progress bar area??? E.g, name + of the current timestamp, and MAYBE some kind of visual breakup of the + progress bar itself? + +TODO: Timestamp editing within mtui itself????????? + +TODO: Automatically expand/collapse timestamp lists in the queue sidebar! + (Done!) + +TODO: Apparently, seeking to a timestamp under a previous track in the queue + doesn't respect the current queue order (i.e. it sticks the track after + the current track). Definitely a bug! + (Done - fixed!) + +TODO: Next/previous buttons should seek between timestamps if there are more + within the same track. + (Done!) + +TODO: Should skipping back to a previous track with timestamps automatically + seek to the final timestamp within that track? I'm undecided, but at the + moment leaning *slightly* towards "no". I may be biased due to it is + harder to code that behavior though! :P + +TODO: The timestamp comment regex should probably skip dashes and other common + punctuation between the timestamp itself and the comment! + +TODO: Pressing ^L to locate the currently playing track (in the queue listing) + should focus the current timestamp, if there is one. + +TODO: I don't think "jump to" (/) works with timestamp items, lol. + +TODO: "Alphabetize order of groups" order option. Listen to the releases of + an artist, or your whole library, alphabetically - or prefix group names + with the date of release and play works chronologically! Or do whatever + other shenanigansy inline metadata you like. + (Done!) + +TODO: "Reveal in queue" option in the context menu for tracks that are part of + the queue! Also, rename existing "Reveal" option to "Reveal in library". + (Done!) + +TODO: Timestamps which have a timestampEnd property (all of them I think?) + should display their duration in the right column. + +TODO: Read timestamps as JSON when the file extension is .json. (Right now + any .timestamps.json file is ignored!) + +TODO: "Remove from queue" seems to always restore the cursor to a non-timestamp + input. This might be an issue with other queue-modifying actions too! + +TODO: The "From: <downloaderArg>" text in the playback info element *does* cut + off its text in an attempt to not go outside the screen bounds... but it + goes over the info pane edges anyway, so there's probably a math issue + there. + +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? + +TODO: Pressing escape while you've got items selected should deselect those + items, rather than stop playback! ...Or SHOULD IT??? Well, yes. But it's + still handy to not be locked out of stopping playback altogether. + Alternative: clear the selection (without stopping playback) only if the + cursor is currently on a selected item. + +TODO: GHOST BACKEND for socket server... the main thing is syncing duration + data. It sucks to have the player, like, actually be tied to a specific + instance of MPV or whatever, so we'd use a ~ghost player~ which supports + all the usual interfaces and lies about its current playback time. Yay! |