| Summary: | Modifications required in how kwin applies blur in wayland | ||
|---|---|---|---|
| Product: | [Plasma] kwin | Reporter: | sk.griffinix |
| Component: | effects-various | Assignee: | KWin default assignee <kwin-bugs-null> |
| Status: | RESOLVED NOT A BUG | ||
| Severity: | normal | CC: | kde |
| Priority: | NOR | ||
| Version First Reported In: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | Other | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed/Implemented In: | ||
| Sentry Crash Report: | |||
|
Description
sk.griffinix
2021-10-22 19:32:43 UTC
>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?
|