Sending a 'closeApp' message allows an app to close a target app, if it
has permission to do so. Currently, permission is granted if the
requesting app is the parent of the target app, or has godmode set.
Send an appClosed message with the instance ID of the app that was
closed. This will be picked up by Puter.js's AppConnection and reported
as a 'close' event.
To make this work, a `data-parent_instance_id` attribute is set on child
app windows. This is very similar to the `data-parent_uuid` attribute,
which tracks parent windows instead of parent app instances. (Dialogs
have a parent window, but are not apps, so don't have a parent app
instance.) The difference is subtle, and we may want to combine these in
the future, but currently closing an app will close any child windows,
which is not behaviour we want for child apps.
This is left open to future additions, by naming it 'locale', and having
the language just be an object field.
Side note, maybe we should have a LocaleService for this?
A broadcast is a message sent to every running app that uses Puter.js.
Broadcasts have a name and a data payload, and are sent as a 'broadcast'
message.
Send a broadcast using:
`globalThis.services.get('broadcast').sendBroadcast(...)`
When doing so, you have the option to keep the broadcast message around,
so that it can be sent to any newly-launched apps. Sending another
broadcast with the same name will overwrite the previous one, so you
don't have to worry about flooding a new app with duplicates.
Previously, we just output whatever err.responseText was. However, that
has some downsides:
- If there's no responseText (as for when we can't find the domain) then
the user gets a blank message.
- If it's a 404 error, the responseText includes the full HTML for
Puter's 404 page, which we don't want to dump in the error box! This
is unlikely to happen in practice, but was easy enough to cater for.
So, add a nicer message in those cases.
The misconfiguration message is taken from here:
https://github.com/HeyPuter/puter/issues/185#issuecomment-2037977592Resolves#235.
Calling `puter.ui.launchApp()` now treats the new app as a child of the
one that launched it.
A child app is given a `puter.parent_instance_id` URL param, containing
its parent's instance ID.
Previously, `launchApp()` would resolve as soon as the app was launched.
This commit changes that, so that it is notified after the child app
sends its READY event to Puter. This means that as soon as `launchApp()`
has completed, the child app is ready to receive messages. The downside
is that launching an app that does not include Puter.js will now not
cause a notification, so `await puter.ui.launchApp()` will not resolve
in that case.
