winit
winit copied to clipboard
rust-windowing
Add option to blur background on macOS
Related to #538
- [ ] Tested on all platforms changed
- [x] Compilation warnings were addressed
- [x]
cargo fmthas been run on this branch - [x]
cargo docbuilds successfully - [x] Added an entry to
CHANGELOG.mdif knowledge of this change could be valuable to users - [x] Updated documentation to reflect any user-facing changes, including notes of platform-specific behavior
- [ ] Created or updated an example program if it would help users understand this functionality
- [x] Updated feature matrix, if new features were added or implemented
This PR adds with_blurred_background to WindowBuilderExtMacOS which makes the view semi-transparent and blurs the background of the window using a NSVisualEffectView.
I think this feature could conflict with other cross-platform implementations, but as there is no standard for blurred backgrounds on Wayland or the web, these features would need to be platform-gated anyway.
Can this be triggered during runtime? I think like it could be done? Limiting it to be enabled only on startup seems a bit lacking for what its worth.
but as there is no standard for blurred backgrounds on Wayland
That's true, I'll ask if there's something not widely supported but still a known way to do things.
on X11 there's no way to do it either, it just some compositors are doing it somehow(some of them just detect transparent background, some rely on properly being set on a window). You can do something for KDE, I guess, inside of winit, but that's it(not sure about GNOME here, maybe there's a way).
Also, can you control the blur effect or it's just a generic blur? If so it'll be nice to provide some control over that to the users.
Yes, I suppose this could be done at runtime, you can disable the blur by setting the state property. The blur effect is determined by macOS, there is a way to add a custom filter with CoreGraphics, but that is a bit more complicated and I'm not sure whether it's allowed on the App Store.
By the way, please don't merge this, the view doesn't resize with the window yet.
By the way, please don't merge this, the view doesn't resize with the window yet.
I have no intent in merging non trivial code on a platforms I can't test, don't worry. But you should open as draft or mark as [WIP] in a title when you open things that you don't want being merged (you've updated that already, but saying for the future).
Also, I'd like to wait for other backends maintainers to chime in and tell how the blur is working on their platforms ( I personally have no idea how it could work on Windows).
cc @Osspial for blur on Windows.
cc @murarth whether winit should set DE specific things like _KDE_NET_WM_BLUR_BEHIND_REGION if the window blur was requested.
As for the Wayland, there's a https://github.com/KDE/kwayland/blob/master/src/client/protocols/blur.xml, which should be pretty straightforward to implement inside of winit( I can submit impl). In general it works in a way that you can request to blur some parts of the window, so if other platforms have such concept we may accept an array of rects (PhysicalPosition, PhysicalSize things) to set blur.
Oh, and you may actually be interested in how the previous effort was going https://github.com/rust-windowing/winit/pull/568 , it had macOS bits working at least.
Thanks for the tip 😉. The resizing works now. About the activation at runtime, IMHO my current design fits better into the style of the transparancy option, having one availiable at runtime and the other not is a bit incoherent. There is however an option in NSVisualEffectView to always blur, even when the window is out of focus, maybe having that availiable to the user is better? At the moment I'm just choosing the default.
About the activation at runtime, IMHO my current design fits better into the style of the transparancy option
The thing is that transparency option doesn't mean that you will or won't have it, and users may draw with alpha 1, so the window will be opaque, however they'll be able to go for opacity only for certain regions, and for those regions they may want to have blur. Requesting blur without ever making blurring the window(user just doesn't trigger a state, where something transparent will be shown) seems strange, and the system may interpret it in a weird way.
even when the window is out of focus
Not sure about that one, but I guess on macOS everyone is blurring even unfocused windows, so that could make a bit more sense?
Not sure about that one, but I guess on macOS everyone is blurring even unfocused windows, so that could make a bit more sense?
No, Finder for example only blurs when in focus. But I guess every app is handling that differently…
No, Finder for example only blurs when in focus. But I guess every app is handling that differently…
Hm, fair enough. That part of when to blur seems macOS specific and could be passed a special window creation attribute for macOS, what do you think?
Sure, that sounds fine. About the activation, the filter allows a mask image to be set, so we can activate the blur for specific zones only. We could implement an API similar to the KWayland protocol (with regions of blur) and have the mask image set to those regions. That would work on both macOS and Linux.
About the activation, the filter allows a mask image to be set, so we can activate the blur for specific zones only. We could implement an API similar to the KWayland protocol (with regions of blur) and have the mask image set to those regions. That would work on both macOS and Linux.
Yeah, it'll be nice to have such control exposed. However I'd like to see how platforms like Windows are working here, I'd assume that they use something very similar, but I can't say anything about it, since I'm not using it.