| Age | Commit message (Collapse) | Author |
|---|
|
Please don't ever let me stay up until 29:57 again. Future me will thank
you in advance.
|
|
Currently bug-free and doesn't change anything about existing mtui
behavior! Meta N to create a new player, meta up/down to switch between
which one you're interacting with. Each player has its own queue.
Eventually (soon(TM)) there'll be much better UI to go with all this!
|
|
The progress label that shows when mtui is processing metadata will
update the screen now.
|
|
|
|
|
|
|
|
Although we don't have any context menu options which start with the
letter G yet, if we did, the keyboard selector would (intentionally)
take priority and focus that element instead of doing jump to start/
bottom behavior. However, pressing Home/End will always work (once it's
implemented).
|
|
|
|
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).
|
|
|
|
...instead of shift+up/down, which I'm going to make select items in
listings (ala graphical file browsers).
|
|
|
|
|
|
|
|
|
|
...and adapt the code to support the scrollbar being hidden (if there
aren't enough items to make the listing scrollable).
|
|
Previously (on Avatar), removing tracks from the queue would cause
a crash if the queue listing was scrolled down. This update fixes that.
|
|
I still prefer recordStore as the cleaner solution, but we were just
doing recordStore.app a lot of the time, and this really wasn't any
better than just passing app.
|
|
..so that your scrollback isn't messed up by mtui's output when you
quit.
|
|
|
|
|
|
I didn't have any luck optimizing buildItems though. It might be
something to come back to some other time. (It's already quick enough to
be usable, even on modland.json, that's for sure!)
|
|
Now you can browse modland.json at your leisure, without the fear of
waiting 10 seconds every time you so much as move your cursor!
|
|
|
|
Mouse is no longer tracked once the process exits, so scrolling the
terminal after closing mtui should work.
|
|
TL;DR mouse should work more reliably within tmux.
|
|
'Cuz hey, why not?
|
|
|
|
Just to see if I can optimize tui-lib's ansi diffing.
|
|
|
|
|
|
Also let the user cancel (esc) the "jump to" to restore the selected
index to wherever it was before.
A neat thing you can do with this: Your cursor will automatically move
to whatever the matched result of your query is while typing. If nothing
is found, your cursor will stay where it was the last time it found
something: so, if you press enter to confirm, AFTER you've queried
something but WHILE your query doesn't currently mathc anything, it'll
keep the cursor at whatever was most recently matched. So basically,
Ctrl-F'ing "excir" will match "Excursions", since "exc" will have
matched it already.
|
|
|
|
Do note the big fat comment.
I'm actually pretty happy with this commit. I think there's a fair
chance that this is the right behavior, and it simplifies a fair amount
of code, e.g. getting rid of manually setting curIndex on this.form and
restoring selection after Dialog.close() (that's handled by tui-lib
now). It also discards the "hack" I had to do to make the AppElement
form capture keyboard input in the first place. (I had to use addChild
with the container paneLeft/paneRight elements so that keyboard input on
their children, which are the inputs of the AppElement form, could be
captured.)
|
|
This significantly improves performance throughout the program while
there is a grouplike listing which contains many items (e.g. upon
queueing a large group).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
..mentioning that you can add stuff to ~/Music to make it show up in the
default mtui playlist.
|
|
Added scrollbars, removed PageUp/PageDown controls
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
