Bug 327567

Summary:	Allow to define xprop variables by rules
Product:	[Plasma] kwin	Reporter:	Nikita Zlobin <nick87720z>
Component:	rules	Assignee:	KWin default assignee <kwin-bugs-null>
Status:	RESOLVED INTENTIONAL
Severity:	wishlist	CC:	yyc1992
Priority:	NOR
Version:	unspecified
Target Milestone:	---
Platform:	unspecified
OS:	Linux
Latest Commit:		Version Fixed In:

Description Nikita Zlobin 2013-11-13 17:12:06 UTC

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

Comment 1 Nikita Zlobin 2013-11-13 17:15:12 UTC

Cases with variables, defining blurring, are only narrow example. Sure, there are more cases when it is handy.

Comment 2 Yichao Yu 2013-11-13 17:32:32 UTC

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?

Comment 3 Thomas Lübking 2013-11-13 18:09:46 UTC

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)

Comment 4 Nikita Zlobin 2013-11-25 02:55:42 UTC

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.

Comment 5 Nikita Zlobin 2013-11-25 03:44:28 UTC

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.

Comment 6 Vlad Zahorodnii 2023-01-24 12:17:18 UTC

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.