Global UI input dispatch / UI resource sharing

[philpax]

At present, each WASM module handles its own input from the WindowKeyboardInput message. This works fine when there's only one module handling UI, but this is unlikely to be the case once we have multiple embers running at the same time.

The current behaviour has its oddities:

• You can enter text into two textboxes at the same time.
• You can accidentally engage UI (buttons, etc) from one module while trying to interact with another module's UI.
• Elements render at the same visual depth, and there's no obvious ordering mechanism (you can set z-depth manually, but how do you know if your window-like should be rendered above someone else's window-like?)

Fixing this will likely require us to consider how we generally "share" resources between embers. The ECS and the messages work well for gameplay, but how do we handle more abstract resources like "visual hierarchy" and "module to accept input"?

The easiest solution would be to hardcode some mechanisms for this into the runtime, so that UI is especially privileged (functions for manipulating the focus stack, requesting a depth to render at for the UI, etc) but it's likely similar problems will occur in other parts of the ecosystem.

See also #620, which was previously contained in this issue.

[FredrikNoren]

Those two issues are quite different. I think focus root can easily be fixed by adding a resource component which all FocusRoot read/writes from (and listens to changes to). The input dispatch is trickier.

[philpax]

My thinking behind putting them together was that they're symptoms of the same problem: sharing global resources where there's no clear owner or ordering.

Using this scenario as an example:

C is a menu bar and A and B are windows. Each of these come from separate modules.

The three issues are:

• the focus root needs to be shared, so that only one window has focus. This can likely be done by chucking it in a resource, as you suggest. It might need to be a stack, so that the previous element is refocused (e.g. on desktop operating systems, going from window A to window B and then closing window B refocuses window A)
• input should only be handled by one module. The naive solution is to use the focus stack, but this means you can't actually change focus by selecting another module's element (i.e. you should be able to click on window A's area to focus it, but clicking on the area of intersection between window A and B should be processed only by B, which is on top). We would need a way of distributing input to all of the modules, and having only the relevant module handle it.
• the three modules need to negotiate z-order somehow. The menu bar is always on top, but A and B should be able to trade places, and you should be able to add a new window D that sits above the other windows, but below the menu bar. They need to negotiate this amongst themselves somehow.

I'll split off the first issue because that should be a much simpler fix, but the other two I'm not really sure how you'd fix them in a "distributed" environment. It seems like you'd need some kind of central broker or to implement some kind of consensus algorithm...