contour via wasm in browser?

[christianparpart]

I just checked. It at least is possible to run qt OpenGL apps in the browser through WebAssembly. This is officially supported.

So the only unknown would be how to execute local executables (shell) and how to read/write config.

[jerch]

:scream: If you want to go that route, maybe I can help here and there.

Some early remarks: Would it be possible to run the the terminal core without Qt as dep? Because that will pull in so many stuff into a wasm build resulting in really bad loading times. The config stuff I suggest to abstract, so it can be managed directly from JS side. Loading of executables? I guess you dont want to deliver an embedded shell, then it is a "someone's else problem" with wasm (bind it via a pty-bridge).

[christianparpart]

• the terminal backend as well as terminal_renderer itself is completely Qt-free.
• for PTY I'm having an abstract interface that can be arbitrarily implemented (I even have a MockPty so I can run unit tests on top of the Terminal API.
• Qt vs wasm: I was actually creating that ticket because I realized that Qt has first-class support for Web Assembly. On the other hand, the only thing I need Qt for is window creating, and rendering into it, and input event capture. I think that can be also done without Qt. If it is just about providing a WASM widget, something that I'd think is the right way, that other web apps can load up and run, then I think we don't even need the contour frontend at all, but just use the existing backend and renderer libraries to create the target .wasm object. (my preferred solution).
• embedding a shell: no, that's what the PTY interface is there for (I have no clue how you are doing that, it's magic to me right now), so yes, the caller should attach stdio to the WASM based widget and can do whatever he wants to do with it. Having a helper JS-Process API to aid that standard purpose might come in handy though. But again, that's all new-ground to me. :)

But, @jerch, I do not want to backstab you and your actual project! :-) I am however curious to see how they perform next to each other.

[jerch]

But, @jerch, I do not want to backstab you and your actual project! :-)

No worries, I am in exploring mode regarding wasm anyway.

I am however curious to see how they perform next to each other.

Indeed, thats an interesting question. Imho the VT emulation part will be faster (2-3 times would be my guess), as long as the rendering can all be done within wasm. If not, you will suffer the same issues we have with our different renderers - any call to DOM stuff will be like hammering through a wall perfwise. The input part will be interesting/tricky - thats actually a really bad hack in xterm.js currently to get most weird key combinations correctly mapped (we have lots of issues regarding that, because browser are not very stable in that field).

[christianparpart]

Font rasterization is easely done in wasm via freetype library. I am more concerned how to get the list of available fonts and load these files. Either i provide a good set of default fonts insid the binary (wise choice as fallback) and/or there will be an API exposed the wasm object user can use to supply the desired font file. Do i have actually wcc SS to the host file system or is that at least possible? (Would be the best case).

[jerch]

What is "wcc SS to the host file system"?

Wasm is a sandbox with almost no access to anything outside. There are attempts to get limited system access abstracted (WASI), but as far as I understand it, thats not meant for browser wasm engines. Means you'd have to load the font files into wasm on your own by some sort of JS-API around it.

[christianparpart]

Do i have actually wcc SS to the host file system...

Damn smartphones.... Let me repeat:

Do i actually have access to the host filesystem

But i think you already have me there answer. I would need a bridging API.