ExportService gets removed and instead a global class registry is added.
The `init.js` file is split into `init_sync.js` and `init_async.js`
so that synchronous code that isn't dependent on imports is guarenteed
to run before initgui.js. The globalThis scope and service-script API
now expose `def`, a function for registering class definitions, and
`use`, a function for obtaining registered classes.
In the first pass I add a `register` method and update `defineComponent`
so it calls `register` as well. This made it possible to create a
proof-of-concept for registered classes. Additionally ExportService was
added to expose registered classes to service scripts. This first pass
works, but it would be better if all types of classes (components or
otherwise) were registered via the same method.
`puter.exit()` now takes a status code, similar to the exit status on
desktop OSes. This is passed to the appClosed event, so that eg a
parent app can know whether its child app ran successfully.
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.
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. :^)
Nariman Jelveh