In my case, the lack of multiple UI threads is blocking.

[theoractice]

Hello, recently I’ve been trying to migrate the UI part of our Brain-Computer Interface prototype from WPF to Avalonia. There's an on-screen keyboard (OSK) in our UI and user (mainly disabled people) can use it to type not only inside our UI but also in other applications outside it.

The problem happens inside our UI. Our WPF implementation uses Raymond Chen's solution here and it worked fine over the years. However, Chen's method uses two separate threads for the two windows shown, and it doesn't fit the single-threaded UI model of Avalonia. If the secondary window (OSK window) is on the same thread of the first window, it always gets activated when user clicks it, causing the first window to lose focus. For other applications outside our UI (windows from other processes), this method still works though.

Currently I have no elegant way to solve this, the only workaround I found is quite hacky and unstable. But I have seen topics like #18586 and #16716, so I want to say that allowing windows on new threads is actually useful, at least on Windows.

FYI here is a demo showing the problem, is there a single-threaded solution?
Demo.zip

[kekekeks]

This is a hard limitation from macOS. You can only make calls to the GUI-related APIs from your first thread.

[stevemonaco]

There may be an approach with running two separate apps in two processes and using IPC to communicate.

[theoractice]

Yes, and in that way we also need to broadcast the BCI control signal to the two processes (or more in the future), so it's a bit of a hassle.