Access window handle?

[MindSwipe]

Is it currently possible to gain direct access to the native window handle for platform specific use?

For example, I'd like to call SetCapture on Windows passing the window handle.

If it's not possible, is it possible to construct a iced Sandbox or Application using a native window handle from something like winit?

[twitchyliquid64]

Is it currently possible to gain direct access to the native window handle for platform specific use?

Not when using iced_winit + Application/Sandbox.

For example, I'd like to call SetCapture on Windows passing the window handle.

From what I can tell, this is equivalent to winit's set_cursor_grab() function?

If it's not possible, is it possible to construct a iced Sandbox or Application using a native window handle from something like winit?

Yes! See the integration example.

[levrik]

That it's not possible to easily get an handle to the window is a huge bummer. I don't want to set up everything on my own just to be able to call a single Win32 API on the window handle in the end. In my case I want to enable the Windows 11 Mica effect through https://github.com/tauri-apps/window-vibrancy which simply requires a window handle but which seems to be impossible to acquire without a ton of complicated work and code duplication.

[genusistimelord]

Maybe this is something we can produce a RFC or something for to try and figure out if there is a good way to handle this without the need for integration. For most users the integration part can seem a bit overburdening to them due to its complexity.

[hecrj]

@levrik Would an additional PlatformSpecific window setting for Windows work for your use case?

https://github.com/iced-rs/iced/blob/cb1aaf1bddd86ef37502602fe0c9d900e8f3f769/winit/src/settings/windows.rs#L1-L12

[levrik]

@hecrj In the end an accessible reference to the winit Window would be enough as it transparently converts to a HWND through raw_window_handle crate.

[hecrj]

@levrik Yes, I am aware. Still, we should try to tackle use cases directly instead of freely exposing internals.

[levrik]

@hecrj Maybe the result of raw_window_handle could be exposed for all platforms? https://github.com/rust-windowing/winit/blob/master/src/window.rs#L1020

[levrik]

@hecrj Please let me know what you think. I'm open to prepare a PR.

[hecrj]

@levrik As I said, I prefer to tackle use cases directly rather than exposing internals.

[genusistimelord]

The thing he wants would need to be ported in as a 3rd party feature if you wanted to tackle it directly. since it requires the window handler to function. This is why he wants to make the window handler public. other than that I see no issue adding it to platform specific stuff. However would it be advisable to create a function to make a new Sandbox or Application taking in a winit window?

Like Sandbox::new_with(window);

[hecrj]

@genusistimelord My point is that we need to evaluate first whether the feature (enabling Mica effect) is something iced should support out of the box.

Exposing the winit::Window (or a window handle) isn't desirable because the API would be lying to users. The runtime has complete control over the window and not the other way around! The user should change it through the runtime itself, not directly.

If you use Application or Sandbox you are giving up control for convenience. It's very important that we do not start blurring the lines of what the different abstractions are meant to solve.

[genusistimelord]

yeah in this case that is understandable. The Mica/blur stuff would be a bit hard to support since it is very OS opinionated.

like apply_blur supports windows (7,8,10,11) apply_mica only supports windows 11 and apply_vibrancy is mac 10.10+ only. Nothing for Linux here. So to support it we would need to implement a part to test which OS it is in order to enable it on that OS if they click the Enable blur/mica effect. If this is OK with you to add these ignore checks based on version then it should be fine to add. I see no issue with a self sustained GUI library containing features for different windows effects. As the goal is to simplify the approach and allow the end user to make nice apps quickly.

[hecrj]

@genusistimelord As I mentioned in my first comment, we already support platform-specific settings. This would be nothing new.

[levrik]

@hecrj I see. I would be willing to give adding this to the platform-specific settings a shot.

A few questions:

• I'm seeing that the platform specific settings aren't exposed to iced::Settings in any way. Just want ensure that this is intended and that I have to override run of my Application struct to set them?
• Probably the best here would be to expand the window builder of winit instead of hacking something on top. Where should I do changes? In https://github.com/iced-rs/winit fork or upstream?

[hecrj]

@levrik

I'm seeing that the platform specific settings aren't exposed to iced::Settings in any way. Just want ensure that this is intended and that I have to override run of my Application struct to set them?

Yes, at least until we decide how to expose these platform-specific settings in the root crate.

Probably the best here would be to expand the window builder of winit instead of hacking something on top. Where should I do changes? In https://github.com/iced-rs/winit fork or upstream?

Ideally, we should contribute back as much as possible to winit. We can start a discussion upstream and get some working code in the fork at the same time.

We should also look at the big picture and consider other window-related use cases like #579, #423, and #124.

[hecrj]

The window handle can be accessed now with the window::run_with_handle command since #2200.