It was part of a general code cleanup effort, which included a lot of things, not just this particular feature. It's a fairly rarely used debugging feature as there aren't that many screen grabbing applications. Thus, its not surprising that it appeared unnecessary during that cleanup.
Posted Jan 30, 2012 21:25 UTC (Mon) by BenHutchings (subscriber, #37955)
[Link]
Almost all X applications use grabs; that's how menus work.
I have a different question...
Posted Jan 30, 2012 21:54 UTC (Mon) by nix (subscriber, #2304)
[Link]
*Server* grabs are much much rarer (and much more dangerous) though. But, yes, keyboard and (especially) mouse grabs are ubiquitous -- and occasionally a buggy app refuses to let go. Hence the usefulness of a break-it option. And the config options of discourse only let you break keyboard and mouse grabs anyway, not server grabs. There is no such thing as a 'screen' grab in the X protocol, as far as I know.
(Aside: I kind of wish that grabs were time-limited unless clients explicitly lifted the limit. That way, screen savers could lift the limit, and everything else would get sanity restored automatically if they buggily failed to release a grab, rather than ruining everyone's day. What you do if a grab expires is another matter. Send a new event, I suppose: killing the client is too evil and emitting an X error is nearly useless because they're too asynchronous so nobody handles them in any way except to kill the app.)
I have a different question...
Posted Jan 30, 2012 23:53 UTC (Mon) by jimparis (subscriber, #38647)
[Link]
> Almost all X applications use grabs; that's how menus work.
Which really sucks, as all keyboard shortcuts (including things like volume keys) stop working whenever there's a popup or menu on the screen. There's no end to how many times this gets reported as a bug: