Some variables are expected to be managed by applications, such as PID and variables, defining areas for blurring for kwin and compiz. Examples, where it would be nice currently: 1. Konsole has a bug, not updating its blur area, and it appears not only with kwin. As recommended on one forum, setting appropriate variable for kwin to 0 makes it to work. But since qtcurve, which is quite popular, breaks it on resize, it may be necessary to refresh it on some known events (such as this). 2. Cairo-dock, compiled with gtk2, is blurred right only by compiz, kwin just blurs entire area, including unpainted. So for now blurruing may be disabled for such windows - imho it would not be problem, since e.g., version, built with default gtk3, is not blurred, but there are enough haters for it :). Reproducible: Always
Cases with variables, defining blurring, are only narrow example. Sure, there are more cases when it is handy.
I don't think any of these are kwin's job. KWin reads (not sets) these properties and draw appropriate blur regions. For Konsole, I don't think it is considered a bug. Although such an option might be useful in konsole. For cairo-dock, which style are you using? Could you try a different style?
Since this is apparently all about blurring, it's more about controlling blur directly. There was short discussion reg. this on the resp. konsole bug and given the wayland protocol, i assume we will much more likely have direct blur control and have it in scripting, where it also allows to react on certain actions (like window resize). For cairo dock, please provide an xprop and xwininfo dump on it - and ideally whether it's blurred by a prticular gtk+ style or cairo dock itself (change gtk+ style to some pixmap like eg. "Milk" and restart cairo-dock) I'd say this is somewhere a bug to be fixed, but the question is "where" (style, cairo-dock, kwin - i kinda doubt that compiz interprets the kwin property)
Using gtk3 - there is no data for both kwin and compiz: $ xprop | grep -i blur nothing For gtk2 need to rebuild to ensure again, but afaik, there was only compiz-related variable. And probably, to achieve such narrow feature, there could be just a support for some compiz properties. Imho, entire blur stuff in kwin looks much less robust, i would say - breakable: breaks by fluid windows movement, doesn't work for menus, created by comboboxes.
Tried again with gtk2. Same xprop command with grep gives only one empty variable - _KDE_NET_WM_BLUR_BEHIND_REGION(CARDINAL), and nothing compiz-related.
With wayland taking on, I don't think it's okay to make window rules temper with X11- or Wayland- specific stuff. If at all, window rules should set protocol-agnostic properties.