Xterm.js produces two kinds of events: onKey and onData. On a desktop,
these are effectively the same, but on mobile, IME inputs produce data
but not key presses. By listening to onData instead of onKey, we get
that input.
With some experimentation, I also found that we don't need the code to
handle enter, home, end, or Ctrl-Shift-V. All of these function as
expected without that code, so we can remove it and simplify this
further. :^)
From version 5.4.0 onwards, xterm scopes its package names as
`@xterm/foo` instead of just `xterm-foo`.
We currently have a copy of xterm.css which we use instead of directly
including the one from the `@xterm/xterm` package, so I've updated the
contents of that too.
We were triggering webserver events in Kernel. This change improves
adherence to separation-of-concerns and ensures event cascading is
working as expected. This also better formalizes the boot sequence.
Every user previously set the max_length as window.TRUNCATE_LENGTH, so
I've moved that constant into the truncate_filename file and set it as
the default if max_length is not specified.
Most of the time, we'll already have a TaskManagerRow for the given
process, so we can just update its properties.
Iterating the results from #iter_tasks means we also insert the rows in
the correct order, regardless of their previous order.
If the Component gets removed from the DOM and then re-added, it already
has contents, and we don't need to create them again. It also has
already had on_ready called, so that doesn't need to happen again
either.
This fix stops Components duplicating their content elements and
listener callbacks whenever they're moved around the document.
This currently behaves the same as it did before: It still recreates the
table contents every half a second. It should also look identical,
though it's possible I missed some small differences.
The component structure is:
TaskManagerTable
- Table
- TaskManagerRow
- TaskManagerRow
- TaskManagerRow
- ...
TaskManagerRow is implemented so that we can later move to modifying
them in place as the process tree changes, instead of having to replace
them all.
Otherwise, most of the code is just moved around, and not changed much.
The object returned from UIWindowProgress() now has a `show_error()`
method, taking a title and message. Calling it will replace the content
of the window with those messages.
I've made use of this for file uploads. The only other place we
currently have errors we could show is for zipping and downloading
files, but we do not always have a progress dialog in that case, so I'll
leave that for now.
I think ideally, we would always create a progress dialog, and it would
then support being invisible initially, but appearing after a delay.
Then we'd always have an object to call `show_error()` on, and it could
then immediately show the dialog. But I'll get to that another day. :^)
