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.
https://bugs.kde.org/show_bug.cgi?id=452780
Nate Graham changed:
What|Removed |Added
CC||n...@kde.org
--
You are receiving this mail
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
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,
https://bugs.kde.org/show_bug.cgi?id=452780
David Edmundson changed:
What|Removed |Added
CC||k...@davidedmundson.co.uk
--- Comment #1
