It's useful to have a working X server if a client holds a grab when it triggers a debugger breakpoint

[Peter Hutterer]

On Mon, May 25, 2009 at 06:21:27PM -0700, Dylan McCall wrote:
> > 
> > I wouldn't disagree that there is a problem for novice programmers,
> > debugging a GUI app for the first time. But for these people, an obscure
> > way to reconfigure their X server doesn't help much either.
> > 
> > - Owen
> 
> I think that debugging example is a fine example, but only a subset of the
> trouble today's state of mouse grabs creates. (And I get the sense David
> is bothered by this issue in a wider sense). The result is that a single
> clueless process (ANY process) can cause a user's system to "lock up" in a
> completely perplexing manner. Try troubleshooting one of these issues over
> the phone. ("Which program were you last using?... okay...  err, type ps
> -A...").
> 
> I will add whoever solves this problem to my list of personal heroes,
> right up there beside Stephen Hawking. If it turns out to be a lot of
> people... well, I guess I'll owe a lot of beer.  I think there are many
> people who think of this the same way.
> 
> I'm sure there are many things that could be done to not have your session
> eaten by a hanging mouse grab if you know it will happen in advance, but
> the fact is something here is very, very wrong and a band-aid doesn't cut
> it. It's either the boatload of GUI toolkits that use mouse grabs, or the
> system that provides the function in the first place.

The main benefit of a grab in the use of menus is that you will get the next
event regardless of where it occurs. This is what makes the menu disappear
when you click elsewhere. If the application didn't grab, the menu could
only disappear by activating a menu item, or - assuming the application
supports this - by clicking elsewhere in one of the application's windows.

Any suggestions on solving this feature through other means is appreciated
(note that registering for events on every visible window doesn't count).

> Just out of curiosity, is there something xinput 2 is doing to resolve
> this? (I at least get the feeling that one could rescue an inoperable
> pointer by plugging in a second mouse with an MPX-crazed distribution.
> Slightly easier to troubleshoot, maybe).

core grabs in XI2/MPX are per master device only, so if you have two
pointers and an app goes rogue on the core grab, you'll still be able to use
the other one on all applications but the one with the grab. Same goes for
keyboards.

It's a bit more complicated than you describe though, since plugging a mouse
in will attach it to the virtual core pointer (the default pointer) and you
need a tool to create a new cursor and reattach the device.

Cheers,
  Peter