SUMMARY As of now, enabling blur effect in system settings blurs menus, kvantum windows, window decorations etc, but does not blur any non-kde window's transparent elements. I guess it is because the application or element has to specially request blur effect to be applied by kwin? This approach is dissimilar to compositors like picom and wayfire, that blur all transparent elements in all applications. Now this problem was easily solvable in x11 where one could just use the force blur script to define applications to blur. This is not perfect as some transparent elements still do not get affected by the script, like the close dialogue box of firefox, but it works for most cases. In case of wayland however, no solution seems possible as of now. I doubt a solution would be even possible without being significantly integrated into kwin. As of now, the only workaround to get blur in non-kde apps in plasma wayland is to run them via xwayland, and then use force blur script for them. This is not remotely close to ideal and not something that will be future-proofed for long. My opinion is that plasma should apply blur effect similarly to wayfire, or provide a method in the effect itself to include/exclude windows. If it is possible in wayfire without loss in performance or apparent smoothness, it should be possible in kwin too. STEPS TO REPRODUCE 1. Install any non-kde app with transparent elements (like alacritty, set value of background_opacity: 0.70 in .yaml file) 2. Run the program in plasma wayland not through xwayland OBSERVED RESULT No blur effect EXPECTED RESULT Blur should be applied, or a method to apply blur should exist
>I guess it is because the application or element has to specially request blur effect to be applied by kwin That's correct. We also have the contrast effect which is similar and with extra metadata that has to come from the client. I don't personally trust that just blurring all non-opaque regions will be without regressions in random clients as we take control away from them. >I doubt a solution would be even possible without being significantly integrated into kwin. There is an existing proposal to allow the kwin rules to do this. That would work for both this case and X11 (and be far less horrible than users running a shell script). Effects already have a code path to read from window properties for the InternalWindow, so we can "just" have a rule set them.
> There is an existing proposal to allow the kwin rules to do this. That would > work for both this case and X11 (and be far less horrible than users running > a shell script). Effects already have a code path to read from window > properties for the InternalWindow, so we can "just" have a rule set them. Is there a bug tracking this proposal?