| Age | Commit message (Collapse) | Author |
|---|
|
Usually this doesn't happen, but it may occur if the items of the
ListScrollForm are regenerated (to a lesser length) before updating
scrollItems.
|
|
TL;DR afterIndex was not being set correctly.
|
|
|
|
This actually drastically improves the performance of mtui when opening
very, very large playlists.
|
|
|
|
Not exactly the most elegant implementation, but it definitely works and
isn't really difficult to code around!
|
|
TL;DR If you want to take into account the width of text, use
measureColumns instead of just checking the length of the text!
|
|
See code comments for explanation.
|
|
|
|
Before: <top>, <bottom>, <second to bottom>, <third to bottom>...
Now: <top>, <second to top>, <third to top>, <fourth to top>...
|
|
|
|
Like mentioned before, it's not too complicated to make these not
bubble - just some added 'return false's.
I wrapped the whole block in a try-finally so that keepCursorInRange
could always be called at the end without any significant code structure
change, so that means the git diff is a little wonky - best viewed with
the -w (ignore whitespace changes) option.
|
|
|
|
This is extremely super duper very breaking in that it reverses the
order that keyboard events are bubbled.
This fixes an issue in the following situation: You have a focus element
which captures keyboard input. When the X key is pressed, a text input,
which is a child (directly or indirectly) of it, is selected and has its
value emptied. As the user types into that text input, if they press the
X key, the handler on the focus element will detect this, and clear and
select the text input - interrupting the user's typing.
The situation is fixed in this commit by making the text input avoid
bubbling events when text is entered. I'm not sure this is 100%
complete, because arrow key events and the like are still bubbled, but
those aren't difficult to change later. The breaking fundamental change
here is that keyboard events are now bubbled from the top element down.
Before, a parent element could deny child elements from responding to
the event; now the child can deny the parent.
|
|
The main purpose of Dialog.opened is to select an input in any case
(e.g. opened() { this.root.select(this.input) }) so it makes more
sense to save whichever element was selected before calling that.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
FocusElement.isSelected behaves a little bit differently - basically
it's true if the current selected element is that element, OR any of the
ancestors of the current selected element is that element. It's also a
getter, so you can't directly override it (assigning to el.isSelected won't
work).
|
|
|
|
Also removed yarn.lock since I don't use yarn for this anymore.
|
|
|
|
|
|
|
|
These are unfortunately based on the assumption that every input is
exactly one character tall, and definitely don't work with horizontal
scrollers, so I had to remove them.
|
|
|
|
|
|
|
|
E.g. if up is pressed in a ListScrollForm, don't tell the parent element
that up was pressed.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
- Whether the cursor is displayed or not is now based on the
cursorVisible property rather than whether cursorX and cursorY
are set or not.
- The actual shell cursor is now invisible... this is objectively
an act of Evil, though! This doesn't look like too hard to
fix, thankfully.
- A new cleanCursor function has been added to ansi.js.
|
|
- Button class name changed to Button, from ButtonInput
- Button layouts are now updated with fixLayout, rather than
automatically when the text property is changed
- Buttons now have a height of 1, so they can generally actually
be used in layouts
- New example for list form elements
- List form elements let you navigate with up/down (or left/right,
for horizontal lists)
- List forms now have nextInput and previousInput methods
|
|
..Obviously this breaks old things (particularly, see changes in
FocusElement).
|
|
|
