[Feature Request] Frosted / Blurry background window support (Windows Acrylic / macOs: Vibrant)

[bric3]

General description What is the motivation for this suggestion.

In order to integrate better with the OS in some aspects, I wonder if it is possible to modify the underlying frame window to be blurry.

There seems be different wording depending on the OS, e.g on Windows the usual term is "Acrylic", on macOs the term is "Vibrant".

This suggestion is:

• [X] Visual
• [ ] Behavioral

From what I've seen elsewhere, it requires a native access to acquire the native window handle in order to modify it. Mich may pose problem if the native symbol is not available, or if the API evolved in some non compatible ways.

• Windows One may try to invoke DwmEnableBlurBehindWindow

  https://github.com/krlvm/SwingAcrylic https://stackoverflow.com/questions/22027247/java-setting-background-from-jar-and-making-it-transparent

• macOs It seems the magic happens with NSVisualEffectView and setting the blending mode to something like NSVisualEffectBlendingModeBehindWindow, which seems to pack some more effects (like corner rounding, whether title bar is vibrant too). https://github.com/wailsapp/wails/blob/801cf3c84ae5c07c1ab31b56e420af4861992d14/v2/internal/frontend/desktop/darwin/WailsContext.m#L175-L184 https://github.com/lukakerr/NSWindowStyles

For Linux I have no idea how this could work, it might depend on Wayland (I don't think this can work on X11) and which compositor is available.

For visual suggestions How do you want the result to look. If possible provide examples or provide a detailed description.

• Windows As I don't have a Windows OS I'm just copying the image from (krlvm/SwingAcrylic)

• macOs

For behavioral suggestions Please provide a detailed description of what should happen at what point.

Additional context Add any other context or screenshots about the feature request here.

[weisJ]

This is a very good idea. Some quick thoughts that I have about it:

• Linux support is probably not feasible IMO.
• I think nowadays Windows uses Mica (on Windows 11) for this kind of effect. Though from the API documentation it is not clear weather it can be enabled after a window is created.
• A component like this would probably need to heavily modify all components above it. Most backgrounds will have to be transparent others probably opaque. Borders most likely can stay opaque (focus rings not so much).
• I‘ll try to add this functionality not be too coupled with the core library so others may make use of it. But in view of my comment above a feature like this will need major cooperation from the LaF to look good (and even be visible)

[bric3]

I believe there's some prior work in particular I've seen stuff o Windows and JavaFX

• https://github.com/dukke/FXThemes (most recent work)
• https://github.com/kieferlam/JavaFX-Blur

~~That said I'm not sure I've seen macOs work on the matter.~~ I've only seen other language runtime doing that.

• https://github.com/carldea/windowblur (JavaFX)

A component like this would probably need to heavily modify all components above it. Most backgrounds will have to be transparent others probably opaque. Borders most likely can stay opaque (focus rings not so much).

I think the mechanism should only work on top windows ? In order to profit from the mechanism child component need to be transparent (opaque = false) I believe.

I‘ll try to add this functionality not be too coupled with the core library so others may make use of it. But in view of my comment above a feature like this will need major cooperation from the LaF to look good (and even be visible)

Does it ? E.g. Could this work by "patching" the Window, and applying the opaqueness / transparency on specific components ?

Thinking out loud: that said maybe it might problematic some type of popups without LaF support, like:

[weisJ]

A component like this would probably need to heavily modify all components above it. Most backgrounds will have to be transparent others probably opaque. Borders most likely can stay opaque (focus rings not so much).

I think the mechanism should only work on top windows ? In order to profit from the mechanism child component need to be transparent (opaque = false) I believe.

Yes with "components above" I meant child windows. M idea would be to apply this on the level of the JRootPane (which then also needs to become transparent) and provide a convenience component which automatically manages the backgrounds for child components.

I‘ll try to add this functionality not be too coupled with the core library so others may make use of it. But in view of my comment above a feature like this will need major cooperation from the LaF to look good (and even be visible)

Does it ? E.g. Could this work by "patching" the Window, and applying the opaqueness / transparency on specific components ?

Even if they are transparent (non-opaque) some LaFs still paint backgrounds e.g. for textfields, comboboxes etc. which may look out of place on an acrylic surface.

Thinking out loud: that said maybe it might problematic some type of popups without LaF support, like:

[...]

It should be straight forward to detect most of those special cases. For example one could only allow this effect on JFrame and JDialog as this already rules out tooltips and popups. Requirements can be relaxed if necessary (and possible).

[bric3]

provide a convenience component which automatically manages the backgrounds for child components.

Even if they are transparent (non-opaque) some LaFs still paint backgrounds e.g. for textfields, comboboxes etc. which may look out of place on an acrylic surface.

That said this may depend on the intended design, E.g. on macOs usually the sidebar can have the frosted effect and the content panel is opaque.

That said I agree if those components have to be on the forsted/blurry/acrylic surface this may look odd. But this feel like a "second" issue than making the JRootPane able to us the OS API to make a window blurry. And there's the OS variations like accent color title bar transparency.

Maybe adding utility method to patch the background in the first place might be enough for this work, then divide the work in another issue to make the LaF support this.