Question: Is it possible to have each TabViewItem content(UI) running in its own process?

[harvinders]

We are creating an application which hosts plugins with their views in a TabView. I would like to understand

Is it possible, today, to host those views in their own processes, similar to what the edge does with tabs?
If not today, are there something in the roadmap that would enable it? What should we be looking out for on the roadmap? AppWindow?
If it is possible or would be possible in future, would that mean, we can have those views based on different versions of WinAppSDK?

[StephenLPeters]

I think this is actually what the Terminal app is doing? @miniksa is that the case?

[zadjii-msft]

This is what the Terminal is working on, but it's not trivial.

Our content is mostly all SwapChainPanels, so we're having each "content process" render to a shared swap chain handle. The "window process" then hooks up that shared swapchain handle to the XAML SwapChainPanel and hosts the rest of the UI (incuding the tabs). So the content process has no idea that it lives in a world of XAML, and the window process is the only one that does. This is the spec I wrote for it (though, it covers a lot of terminal-specific topics that might not all be relevant). The "Window and Content Processes" is the part that's relevant here.

Ours is not a plug-and-play solution. If you were doing anything more complex with your tab content, if you had elaborate XAML layouts per-tab, then this wouldn't work. XAML objects can't cross thread or process boundaries, so you can't have the content process hosting some tree of XAML, then hand that off to the window process to host in the window's UI tree.

If you have a generic way of describing the content of your tab, then you could presumably communicate that to the window process and have the window render the UI on the content processes behalf. So, the window process would be responsible for the "View", and the content would be responsible for the "Model".

I can't really comment on any other future plans by the WinUI or WinAppSDk team though. This was just our solution, and it's not even totally done for the Terminal yet 🙃

[StephenLPeters]

@jevansaks and @MikeHillberg thoughts on if there are other solutions?

[miniksa]

Honestly if there's another easier answer to this question, we're going to cry on the Terminal side.

[jevansaks]

Honestly if there's another easier answer to this question, we're going to cry on the Terminal side.

Ha!

Sadly for @harvinders (but happy for @miniksa ?) there is no easier solution today. Cross-process and cross-thread islands are something we want to make easy, but I couldn't say when.

Things like WebView2 (which are a homegrown cross-process island if you think about it) are a whole lot of special work to get right. I wouldn't recommend it, but you could take a look at that code to be inspired about what you would need to do. Output redirection is easy but getting input forwarded and UIA/IME connected is not super fun.

+@jeffstall

[miniksa]

(but happy for @miniksa ?) there is no easier solution today.

Hah. Not strictly happy. I was just going to be frustrated if we spent a long time trying to figure out how to do this and the answer was just around the corner and we failed to see it.