| Age | Commit message (Collapse) | Author |
|---|
|
|
|
The biggest change here is moving various element classes under
more scope-specific directories, which helps to avoid circular
dependencies and is just cleaner to navigate and expand in the
future.
Otherwise this is a largely uncritical port to ESM module syntax!
There are probably a number of changes and other cleanups that
remain much needed.
Whenever I make changes to tui-lib it's hard to believe it's
already been <INSERT COUNTING NUMBER HERE> years since the
previous time. First commits are from January 2017, and the
code originates a month earlier in KAaRMNoD!
|
|
This caused clicks not to match the context menu in mtui, where the
container layer (a full-screen element) is marked clickThrough: false
(but the menu and its elements are not). Basically this meant clicking
menus has been broken for however long this code has been here.
|
|
|
|
I Am Very Good At Managing Npm Repositories
|
|
|
|
|
|
|
|
|
|
It's no longer strictly connected to a ListScrollForm, and is published,
so it's much easier to use as an element from the tui-lib API in any
project now.
|
|
|
|
|
|
This makes the screen be automatically redrawn whenever a label's text
is updated.
|
|
I think this'll take some serious attention before it even works and
saves any performance.
|
|
|
|
|
|
|
|
This is a very large change and probably breaks most applications not
built to work with it. (Obviously, I'm not really being that responsible
with this sort of thing.) I've tested with mtui and it works fine, but
some elements may need tweaks before being 100% adjusted to the new
scheduled-render system we're using with this commit. Also, any elements
which have custom draw behavior will likely need updating so that they
appropriately schedule renders.
|
|
|
|
|
|
...for mouse events. Contains cursor position, modifier keys pressed,
etc.
|
|
...depending on whether there is enough content that it cannot all be
displayed in the form's space or not.
|
|
Specifically, it now clearly represents how much of the scrollable form
is visible and not visible at the moment. It also will never touch the
top or bottom if it's possible to scroll further in the correspodning
direction.
|
|
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.
|
|
|
