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

[Dylan McCall]

> 
> 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.

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).


On a lighter note: Thanks for the debugging tips, Owen :)


-Dylan McCall
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://lists.x.org/archives/xorg/attachments/20090525/d8c09fce/attachment.pgp>