diff options
Diffstat (limited to 'todo.txt')
| -rw-r--r-- | todo.txt | 172 |
1 files changed, 169 insertions, 3 deletions
diff --git a/todo.txt b/todo.txt index 726e04f..63ba2e2 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. @@ -592,6 +589,7 @@ TODO: The checks for "grouplike"/"track" have been super arbitrary for a long TODO: Synchronize items that have been shared with the party upon a new client joining. Should be next to (or part of) the initialize-backend command. + (Done!) TODO: We currently use a hack to access the original item in the context menu for items in the party sources listing. This doesn't make, for example, @@ -599,3 +597,171 @@ TODO: We currently use a hack to access the original item in the context menu to specifically refer to the item "represented" by a line, rather than the literal object it's associated with (i.e. the pseudo-track/group shared in the sources array). + +TODO: Broadcast when a socket disconnects; show a log message and remove their + shared sources from the UI of other clients. + +TODO: Ditto for the server! Not (exclusively) as a broadcast message, though - + detect if the connection to the server is lost for any reason. + +TODO: The validation code for share-with-party sucks! It should be made into a + separate function which runs recursively, and should be used to validate + initialize-party too. + +TODO: Show debug log messages when validating a command fails! On both server + and client end. + +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! + (Partway: The ghost player exists now, and the backend and UI handle it! + Just need to hook up a "dummy" backend for the server, with ghost player + and duration metadata received from socket clients.) + +TODO: There should be a way for the server to handle disputes between two + clients disagreeing on the duration of a track. Options could include, + for example, "longest": always wait for everyone to be done playing; + "shortest": don't wait for anyone to be done (past a 1 second threshold + or whatever), just skip to the next track almost right away; and "first", + where duration just depends on whoever shared the track. This can all be + done without everyone sharing their own playback duration, which is kinda + wasteful; it would be controlled totally by the server deciding when to + send out events to start the next track, and in reaction only to the + clients' own "done playing" events (or the GHOST PLAYER reaching the + playback time provided when the track was first shared). + +TODO: Implement a waaaay better socat system, particularly one which waits for + feedback when a command is sent and returns that. This has to be special- + coded for mpv since there isn't a generalized standard, so it should make + use of the existing Socat class, not replace it outright. + +TODO: Use above socat system to keep "pinging" the socket until a response is + received - mpv doesn't make the socket immediately available. I think if + we wait for a pong response before allowing any actual commands to go + through, we can avoid weirdness with commands being dropped beacuse they + were sent too early. For now we just use a time-based delay on the base + Socat class, which is a hack. |