https://bugs.kde.org/show_bug.cgi?id=452780
--- Comment #4 from Alberto Salvia Novella ---
I suspect it's just simpler to expose the structure as it is, and let the
developer figure out the use case versus anticipating all the plausible
scenarios. Aka separating the policy from the mechanism.
Th
https://bugs.kde.org/show_bug.cgi?id=452780
Nate Graham changed:
What|Removed |Added
CC||n...@kde.org
--
You are receiving this mail beca
https://bugs.kde.org/show_bug.cgi?id=452780
--- Comment #3 from David Edmundson ---
I see your point. Though I don't want to introduce a two properties on each
client which are maybe in sync maybe not and still have it still awkwardly
racey.
What I think we would want is:
- API to write directl
https://bugs.kde.org/show_bug.cgi?id=452780
--- Comment #2 from Alberto Salvia Novella ---
They are independent. `NET_WM_BYPASS_COMPOSITOR` (aka the hint) is what the
window requests, and `blocksCompositing` (aka the property) is what kwin is
currently doing with it.
The hint is inmutable, where
https://bugs.kde.org/show_bug.cgi?id=452780
David Edmundson changed:
What|Removed |Added
CC||k...@davidedmundson.co.uk
--- Comment #1 from
