Feature Request: Add a way to make a window "always-on-top" of a native window from another process.

[colugomusic]

I think this is quite an esoteric feature request but it would help me a lot for my use case.

I am using nappgui to launch audio plugin windows in an audio application. The audio plugins are "sandboxed", meaning they run in a separate process from the main application.

The main application does not interact with nappgui at all. It only launches a separate sandbox process, and the sandbox process uses nappgui to create the plugin windows.

In audio applications, it is very common that when an audio plugin window is open, it will always be displayed on top of the main application window, meaning if the user clicks on the main application window, the plugin windows would not be hidden behind it when the main window comes to the foreground.

On WIN32, the best I can do right now is top simply set all editor windows to be "always on top", meaning it will be always on top of ALL other application windows, which can be done something like this:

auto setup_editor_window(const sbox::device& dev) -> void {
	const auto view_hwnd = (HWND)(view_native(dev.ui.view));
	const auto top_hwnd  = GetAncestor(view_hwnd, GA_ROOT);
	SetWindowPos(top_hwnd, HWND_TOPMOST, 0, 0, 0, 0, SWP_NOMOVE | SWP_NOSIZE);
}

Instead I really want to be able to pass the main application window's native handle to nappgui, and have the nappgui window always be on top of the main window (even though the windows belong to separate processes.) As far as I know the only way to do this on Windows would be by using SetParent to set the main application window to be the parent of the nappgui window.

On Windows it is legal to set a window that belongs to another process as the parent, so I assume that this is how other audio applications are achieving this behaviour (on Windows at least.)

I'm not sure how to achieve the same effect on macOS and Linux. I assume the concepts there are a little different.

Of course I cannot currently call SetParent myself to set this up, because nappgui makes certain assumptions about the parent/child relationships of windows. (For example it assumes that calling GetAncestor(hwnd, GA_ROOT) on a nappgui window will always return another nappgui window.) There are probably other complications too.

I hope this makes sense. It would be really nice to have an interface to set this up in nappgui, perhaps something like a window_native_parent(void* native_window). Though I mainly develop on Windows so I'm not sure yet if this also makes sense for macOS and Linux.

[frang75]

Hi @colugomusic. Yes it make sense.
In Windows it would be more or less clear. The case would have to be investigated in GTK and macOS. Since they are different processes, the operating system could hide the plugin windows with the main window.

Another different case would be that the main program could launch NAppGUI windows in the same process (not sandbox), but without creating a NAppGUI application. That is, a third-party application with NAppGUI windows. This case would be contemplated in the issue #100.