window-vibrancy feat!: fix liquid_glass layering and add opaque background option

Fixes #198 and enhances the apply_liquid_glass API with improved layer management and customization options.

Changes

1. Fix WebView layering and corner radius issues

Resolves edge misalignment by reparenting the WebView into the glass view's contentView instead of placing it as a sibling. This ensures proper layer hierarchy and correct corner radius rendering.

2. Add opaque background option

The Glass Effect View's high transparency can be problematic. Adding a background directly in the WebView blocks the liquid glass effect. This introduces an optional opaque parameter that creates a separate NSBox background layer positioned below the glass view, preserving the glass effect while providing background control.

3. Refactor API with `LiquidGlassOptions` struct

Breaking Change: Consolidate parameters into a structured options object for better ergonomics.

Before:

apply_liquid_glass(&window, style, tint_color, radius)

After:

apply_liquid_glass(&window, LiquidGlassOptions {
    style: NSGlassEffectViewStyle::Clear,
    radius: Some(26.0),
    opaque: Some(false),
    ..Default::default()
})

Nov 22 '25 05:11 ahonn

Resolves edge misalignment by reparenting the WebView into the glass view's contentView instead of placing it as a sibling. This ensures proper layer hierarchy and correct corner radius rendering.

The reason why i didn't copy your changes into this repo yet is because i don't think we should have webview specific code here. If possible i'd rather expose an option for the contentView and let users specify the webview themselves. Most users won't even see this since we do that for them in Tauri.

This introduces an optional opaque parameter that creates a separate NSBox background layer positioned below the glass view, preserving the glass effect while providing background control.

I'll try to check it out later but what glass effect is left when you have an opaque background and what's the difference from a opaque webview background (eg either wkwebview's "native" background or just the html/css color)

Refactor API with LiquidGlassOptions struct

I don't think this fits the style of this crate tbh.

Nov 22 '25 09:11 FabianLars

The reason why i didn't copy your changes into this repo yet is because i don't think we should have webview specific code here. If possible i'd rather expose an option for the contentView and let users specify the webview themselves. Most users won't even see this since we do that for them in Tauri.

I agree that having WebView-specific logic inside this crate isn’t ideal. My implementation was mainly a pragmatic fix for my own app, and I don’t think it’s necessarily the right abstraction. Exposing a contentView option and letting users attach their own WebView sounds like the cleaner long-term approach, and I’m happy to adjust the PR in that direction.

I'll try to check it out later but what glass effect is left when you have an opaque background and what's the difference from a opaque webview background (eg either wkwebview's "native" background or just the html/css color)

Based on my tests, an opaque WebView background blocks the glass effect completely. But an opaque layer under the glass still preserves the system tinting. You can verify this easily by moving the window over a strong-colored background, the glass keeps its subtle tint, while an opaque WebView background removes it.

I don't think this fits the style of this crate tbh.

That makes sense. I agree it doesn’t fully match the crate’s current style. I only grouped the parameters because there were getting to be a few, but I’m completely fine reverting to the original API approach.

Nov 22 '25 12:11 ahonn

Exposing a contentView option and letting users attach their own WebView sounds like the cleaner long-term approach, and I’m happy to adjust the PR in that direction.

awesome, that would be appreciated :)

Based on my tests, an opaque WebView background blocks the glass effect completely. But an opaque layer under the glass still preserves the system tinting. You can verify this easily by moving the window over a strong-colored background, the glass keeps its subtle tint, while an opaque WebView background removes it.

got it, sounds reasonable then.

That makes sense. I agree it doesn’t fully match the crate’s current style. I only grouped the parameters because there were getting to be a few, but I’m completely fine reverting to the original API approach.

If we keep the opaque option and add a contentView option then it's indeed getting a bit much and i'm okay with keeping the options in that case though i'd like to hear @amrbashir opinion on that if he has one.

Nov 22 '25 12:11 FabianLars

I don't mind changing the API, we can even extend the same pattern to other platforms as well. My only concern is proofing against future breaking changes, so I would suggest to not make the structs fields public and provide a builder-pattern struct (or just methods on same struct).

Nov 23 '25 02:11 amrbashir

Thanks for the suggestions!

I've exposed a generic content_view() option instead. This keeps the crate framework-agnostic while still solving the layering issue. For the API style, I've converted options to use the builder pattern as @amrbashir suggested. The WebView detection logic has now been moved to the tauri example as a reference for users who need it.

Nov 25 '25 23:11 ahonn

Review the following changes in direct dependencies. Learn more about Socket for GitHub.