blur: add blur_border config

[the-eater]

expands the Exciting and New blur node to fit whole window!

[the-eater]

blur_border	<value>
yes
no

[WillPower3309]

Have we tested with stack / tabbed layouts with borders off (just titlebar should blur)?

[WillPower3309]

nit: 2 spaces before ?

[WillPower3309]

cleanup suggestion:

int blur_corner_radius = 0;
if (closest_con && container_has_corner_radius(closest_con)) {
    blur_corner_radius = corner_radius;
    if (closest_con->blur_border) {
        blur_corners = CORNER_LOCATION_ALL;
        blur_corner_radius += closest_con->current.border_thickness;
    }
}
wlr_scene_blur_set_corner_radius(blur, blur_corner_radius, blur_corners);

[WillPower3309]

One more nit: blur_decorations may be more descriptive as it includes titlebars

[ahfriedman]

Have we tested with stack / tabbed layouts with borders off (just titlebar should blur)?

I did some testing with this PR today. The current changes do not impact tabbed/stacked containers. I'm still figuring out the source code, but I think the issue is that, for tabbed/stacked windows, the titlebar is created separately as part of arrange_children. As such, its extents aren't taken into account by the current code. Moreover, because the children themselves have blur, adding the code to position to blur in arrange_children (I suspect) would cause potential conflicts when the children themselves attempt to reposition the same blur when arrange_container gets called on them. As a novice, it would seem like the best solution to this might be to give the titlebars a unique blur node of their own. After all, I could see that potentially helping out PRs like #457. I'd be happy to try to play around with that idea (or any other suggestions you have to get this to work).

[WillPower3309]

Have we tested with stack / tabbed layouts with borders off (just titlebar should blur)?

I did some testing with this PR today. The current changes do not impact tabbed/stacked containers. I'm still figuring out the source code, but I think the issue is that, for tabbed/stacked windows, the titlebar is created separately as part of arrange_children. As such, its extents aren't taken into account by the current code. Moreover, because the children themselves have blur, adding the code to position to blur in arrange_children (I suspect) would cause potential conflicts when the children themselves attempt to reposition the same blur when arrange_container gets called on them. As a novice, it would seem like the best solution to this might be to give the titlebars a unique blur node of their own. After all, I could see that potentially helping out PRs like #457. I'd be happy to try to play around with that idea (or any other suggestions you have to get this to work).

thanks! We have a similar issue here as we do for drawing shadows on tabbed / stacked containers... I don't think this is currently handled elegantly so you could either look to the shadow logic for how to do the blur or come up with something better.

I suspect we can do this in the arrange_container logic by getting the y_offset of the parent container (int y_offset = con->current.height - height;) and then using this to position the blur node.

[WillPower3309]

we'd need a rebase too!

[the-eater]

quick comment, which hopefully reduces some work, you don't want to give titlebars their own blur node, because the blur nodes will sample each other if you do that, causing a dark shadow to appear on the blur node which is scheduled last. if blur decoration is enabled you probably want it to start function alike shadows where its only enabled in the parent container and the rest is disabled.

…

On May 1, 2026 11:05:03 PM GMT+02:00, Alex Friedman ***@***.***> wrote: ahfriedman left a comment (wlrfx/swayfx#473) > Have we tested with stack / tabbed layouts with borders off (just titlebar should blur)? I did some testing with this PR today. The current changes do not impact tabbed/stacked containers. I'm still figuring out the source code, but I think the issue is that, for tabbed/stacked windows, the titlebar is created separately as part of `arrange_children`. As such, its extents aren't taken into account by the current code. Moreover, because the children themselves have blur, adding the code to position to blur in `arrange_children` (I suspect) would cause potential conflicts when the children themselves attempt to reposition the same blur when `arrange_container` gets called on them. As a novice, it would seem like the best solution to this might be to give the titlebars a unique blur node of their own. After all, I could see that potentially helping out PRs like #457. I'd be happy to try to play around with that idea (or any other suggestions you have to get this to work). -- Reply to this email directly or view it on GitHub: #473 (comment) You are receiving this because you authored the thread. Message ID: ***@***.***>

[ahfriedman]

Thank you both! I've opened a draft PR to track the status my attempted fixes to this (#527). While the offset suggestion seems to mostly fix the issues with tabbed/stacked containers, there still is a bug that I encountered when adding the logic to handle nested tabbed/stacked containers that I havent yet figured out. If you have a few minutes, would be happy to get your thoughts on it.