C++ Raw Window Handle #6248
Replies: 2 comments 1 reply
-
Right, we should add API to get the raw window handle as a void* in C++ Do I understand correctly that you're not using Slint do implement the VST plugin, but instead, want to display VST plugins from a Slint application? But there is still the option of using native windows without winit as Slint can be drawn on native window with the Slint Platform API We have a class NativeWindowHandle in our C++ API, but it is used to give the pointer from the application, to Slint. Not the other way around. |
Beta Was this translation helpful? Give feedback.
-
If you were to implement the raw window handle for C++, you'd need to add a getter in the Rust FFI. (as an example, you can see the getter for the position) https:/slint-ui/slint/blob/master/internal/core/window.rs#L1427 class Window {
//...
std::optional<std::tuple<HWND, HINSTANCE>> win32_handle() const;
std::optional<std::tuple<NSWindow*, NSVIew*>> appkit_handle() const;
// ... Or maybe std::tuple is not a great API and we need a more specific struct, bool win32_handle(HWND &hwnd, HINSTANCE &hinstance) const; Not sure what is best, none of these options sounds super great to me. |
Beta Was this translation helpful? Give feedback.
-
Relevant: #5107
I'm working on a VST plugin host project. Since the SDK is written in C++, it's been quite difficult to get it off the ground in Rust. Part of what I need to do is open a blank window and provide the plugin with a pointer to said window so it can draw it's editor. In Rust with native
winit
, I could basically just grab theRawWindowHandle
and transform it into a*mut c_void
.From the linked discussion, it seems the same solution is not available using Slint in C++ as it isn't yet exposed to the C++ API. But I also am wondering if this is even the best way to go about it in a framework like Slint. Will Slint be trying to compete with the plugin to render onto the window?
We'd like to use Slint as a solution for our general app interface, but also have this additional requirement of drawing editors for VST plugins. My limited testing has seemingly ruled out using native windows for this as
winit
doesn't like to be run on a non-principal thread and (at least on MacOS) the native frameworks also have this preference. So, it makes sense to try to use Slint to manage both sorts of windows.Another idea I've had is to make "virtual windows" of sorts -- some kind of sub-surface that the plugin will treat as a window but which only exists inside of the Slint ecosystem. Is this doable?
Any feedback would be appreciated.
Beta Was this translation helpful? Give feedback.
All reactions