Merge the Windowing proposal

[tareksander]

I changed mini-canvas to window and consolidated the event listeners into it, as well as adding my event definitions from the Windowing proposal. I also made my events pollable-based like you suggested and made a pollable for each event type. Creating resources for each event listener seems too much, I kept the functions in the window resource.

I also added an alternative display API as an example that more display APIs are possible and for possible embedded use.

[MendyBerger]

Thanks @tareksander for putting this together, I like where this is going!

I've added my questions and suggestions.

Creating resources for each event listener seems too much, I kept the functions in the window resource.

Good idea! I didn't think of it.

[MendyBerger]

What does this mean? Why would you even be able to get here, when there's no windowing capabilities?

[tareksander]

Yeah. You talked about the possibility of having multiple presentation APIs, and I also added an API intended for raw framebuffer access on connected screens, for embedded devices. If this were Rust, I'd just make the window constructor return an option, but I don't think that's possible in WIT?

[MendyBerger]

Wit does support options: e.g. option<bool> instead of bool.

But I'm not sure I'm following why this is necessary. If another presentation api is used, how would you reach this point at all?
You would use wasi-windowing-other instead of wasi-windowing, and wasi-windowing-other would have a completely different set of functions.

[tareksander]

Currently the unit of implementation is a world. So if something is included in the world, you have to implement it, even if it's stubbed. Since I can't make the constructor fail gracefully, there needs to be a function to query runtime support. Of course each display API could get its own world, too.

[tschneidereit]

If this were Rust, I'd just make the window constructor return an option, but I don't think that's possible in WIT?

The way to do that in WIT is to use a static factory function:

ctor: static func([...]) -> option<the-type>;

[MendyBerger]

Of course each display API could get its own world, too.

That's what I'd prefer.

[MendyBerger]

Any reason you're calling these mouse instead of pointer? I would opt for pointer, like the web, because we wanna cover all kinds of inputs, like touch and pencil.

[tareksander]

Touch input is a bit more complicated, with multi touch and all, I haven't looked at touch yet. There will be separate events for pointers, but implementations are free to convert e.g. a tap into mouse-down + mouse-up.

[MendyBerger]

I'd start with pointer since it covers all the basics (mouse, pen, touch). We can later add in things like multi touch, but I'd prefer if we can start with something broad rather than something narrow.

[Clunt]

我会从指针开始，因为它涵盖了所有基本功能（鼠标、笔、触摸）。我们稍后可以添加多点触摸等功能，但我更希望我们能从广泛的内容开始，而不是从狭窄的内容开始。

strongly agree like https://developer.mozilla.org/zh-CN/docs/Web/API/Pointer_events

[MendyBerger]

How's this different from frame-buffer.wit?

[tareksander]

This is a display API, frame-buffer is a graphics API. But you're right, the intended use is to connect a display to a frame-buffer to draw into, primarily for embedded devices. The difference is that frame-buffer is an arbitrary framebuffer, but this maps to hardware displays and their framebuffers. This is just a proof that multiple display APIs are supported, we don't have to actually include it.

[MendyBerger]

Any reason we can't use frame-buffer for both?

[tareksander]

frame-buffer has no way to specify a screen, or which screen.

[MendyBerger]

I see.
But I'd much rather have one interface for both.
Wanna open a separate issue or PR to discuss?