| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Somebody remind me to write unit tests...
|
|
This was already half-done, but the new behavior in this commit feels
quite a bit nicer. (Specifically if you use shift-up/down (or n/p) while
the queue is selected, the cursor will move to the new selection if it
was already on the old selection, whereas before it would never follow
when the queue was selected.)
|
|
|
|
This also makes it so that the selected options in whereControl and
orderControl stay the same when you open the context menu on a different
item, browse a different group, etc.
|
|
E.g. to interweave two groups together.
|
|
|
|
This should be more intuitive and useful...most of the time. :)
|
|
Cool! This was one of my favorite tiny features of http-music.
|
|
Not a lot of new potential utility here for now, but it's at the least
easier to use and cleaner than the old look! Also.. shuffle-groups
soon(TM). Maybe!
|
|
|
|
|
|
Used to access a menu for the playlist that's currently being browsed.
Particularly handy for working with the top-level group, since you can't
access its menu any other way. Also useful for quickly acting on a group
you opened from (for example) a PathElement.
|
|
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!)
|
|
This doesn't impact performance noticeably, it's just a code nitpick.
|
|
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.
|
|
Scroll up/down to seek, click to toggle pause.
|
|
'Cuz hey, why not?
|
|
|
|
Just to see if I can optimize tui-lib's ansi diffing.
|
|
|
|
This way you can activate the menu without taking your right hand off
the arrow keys (in typical keyboards).
|
|
It's not really practical for use right now. Well, more like I haven't
figured out *what* the "ordinary use" is.
|
|
|
|
Oops! I got rid of (well, tweaked) the concepts of "real" and "fake"
rows, but forgot to get rid of the now-unnecessary (and disfunctional)
isReal checks.
|
|
|
|
I.e, the "Up (to group)" button and the "(This group is empty)"
pseudo-playlist-item.
|
|
Specifically, don't bubble escape when it's pressed in ContextMenus or
in ListingJumpElements.
TL;DR you won't accidentally cancel your currently playing song as much.
|
|
|
|
|
|
Moved .on('resize') to be after the flushable is actually created, so we
don't get an error (flushable is not defined) when resizing before the
flushable has been created. Also checked for size only immediately
before we actually display, so that the size is accurate right away.
|
|
See #1.
Also fixed a bug where shift-up/p wouldn't queue a track at the top of the
queue when the top was selected.
|
|
|
|
This happened when the openPlaylistDialog was closed before being
opened - Dialog.close would try to select(this.oldSelectedElement),
but of course that would be undefined since the dialog had never been
opened in the first place.
|
|
|
|
It's not supposed to do that. (It's supposed to swap between the path
element and the listing itself.)
|
|
Also make submodules point towards notabug.
|
|
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.
|
|
This is foundation for actively highlighting the result of a jump-to
while typing. (Since your focus is on the ListingJumpElement, there
needs to be some way to see which item would be selected in the
GrouplikeListing. That's what this commit implements.)
This also looks pretty nifty when you press M to open the context menu,
if I do say so myself.
|
|
|
|
|
|
Path elements were and are horizontal scroll forms composed of path item
elements. Previously they were separated like this (each "(x)" is a
different path item element):
(My ~/Music Library >) (C418 >) (72 Minutes Of Fame >) (03 Alive)
Now they're separated like this:
(In: My ~/Music Libary) (> C418) (> 72 Minutes Of Fame)
There are two changes here:
* The last item, i.e. the selected item itself, is no longer a part of
the path display. In practice this wasn't actually a very useful
button, and now the path element is more useful in how it was designed
to be used: as a way to jump to the group which a selected track is
in. (This is emphasized by the new "In:" label at the start of the
first path element.)
* The "arrow label" part of the element is now placed on the left of the
element instead of the right. Before, all but the last item had a ">"
in their arrow label; now, all but the first do. (The first item has
the text "In:" instead.) This is so that it's clear when the path
element has been scrolled to the right and the first/leftmost items
are cut off; if any are cut off, the first visible element will start
with ">" instead of "In:".
|
|
|
|
The repro:
1. Press tab to select the path element.
2. Press 2 (or 1) to switch to a different grouplike listing.
3. Press 1 (or 2) to switch back. Note that the root.select()'ed element
is the grouplike listing's form, i.e. the list of tracks/groups, not
the path element.
4. Press tab. Note that the root.select()'ed element does not change.
This fixes the issue by setting curIndex to 0, which is the index of the
grouplike listing's form. This makes the tab key behave correctly and
select the path element in step 4.
|
|
|
|
|
|
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.)
|
