« get me outta code hell

Only render when stuff on-screen actually changes! - mtui - Music Text User Interface - user-friendly command line music player
about summary refs log tree commit diff
path: root/todo.txt
diff options
context:
space:
mode:
authorFlorrie <towerofnix@gmail.com>2019-09-15 17:17:31 -0300
committerFlorrie <towerofnix@gmail.com>2019-09-15 17:17:31 -0300
commit8053f12b63e272cc9119a30f9ddc480b5ea75641 (patch)
treee52eee3680eef45032cbc5acc3e49838b9fc6378 /todo.txt
parent6be85bb511f9e3e55ab503c9b8b44afb31b84f2d (diff)
Only render when stuff on-screen actually changes!
This means we can basically guarantee 0% CPU usage when nothing on the
screen is changing! There may still be some kinks to work out, but I've
tested most features and fixed any apparent bugs (including an unrelated
bug in the suspend feature which made it crash when resuming the process).
Diffstat (limited to 'todo.txt')
-rw-r--r--todo.txt37
1 files changed, 37 insertions, 0 deletions
diff --git a/todo.txt b/todo.txt
index eba924c..6af1370 100644
--- a/todo.txt
+++ b/todo.txt
@@ -333,3 +333,40 @@ TODO: Default to 'after selected track' in context menu, and make pressing Q
       really only useful when you're building a queue at the start, assuming
       you don't start by shuffling your entire queue anyway).
       (Done!)
+
+TODO: When grouplike listings are fixLayout'd (e.g. the window is resized),
+      make sure the selected input is still visible!
+
+TODO: If you press any key which should select a particular element of the UI
+      (e.g. the menubar) while a context menu is open, currently the context
+      menu will close and then restore selection to the element which was
+      selected when the menu was opened. This seems to happen after the target
+      element is selected; the effect is that any key which is meant to focus
+      specific UI parts instead closes the context menu while one is open.
+      We already have a key for doing just that (the cancel key, i.e. esc or
+      period), so fix this!
+
+TODO: g/G should work for navigation in context menus! And probably all
+      ListScrollForms, tbh, but I'm kinda weary of introducing new behavior
+      like that to tui-lib.
+
+TODO: PageUp/PageDown support is complicated to implement (I've tried) and
+      should come eventually, but for now just make Home/End work as aliases
+      for g/G. This means making it possible for the keybinding system to let
+      a single input function return true for multiple different keys!
+
+TODO: Work out the BIGGER framerate shenanigans. Specifically: down with the
+      render interval! Or, more literally, get rid of it altogether. Only
+      render when we know the on-screen text is going to have changed.
+      (Done - Huzzah! We use 0% CPU when not actively updating the screen now.)
+
+TODO: Be more sneaky about how we decide what text to update on the screen,
+      in a way which saves us performance. Instead of going through the whole
+      ansi.interpret process, predict which regions of the screen are going to
+      have updated, and only process those spaces. We can guess reasonably by
+      looking at which elements caused the screen to update (keep track of this
+      in the Root, through the shouldRenderTo function).
+
+TODO: Create a basic Element class, which DisplayElement extends. We have a lot
+      of code related to scheduling displaying stuff on the screen, and it'd be
+      nice to keep it more separate from all the basic element logic.