Removal of XFree86-Misc

[Bill Crawford]

[ I hope I have the attributions right ... ]

2008/7/16 Paulo Cesar Pereira de Andrade <pcpa at mandriva.com.br>:
> Adam Jackson wrote:
...
>> In the absence of API to control Allow{Deactivate,Closedown}Grabs from
>> the client side, I suggest we should take those options out of the
>> config file entirely.  Input people, any opinions?

>  I am not 100% sure, but I think the kde screensaver also uses it.

I already commented on this, but I think screensavers should be able
to insist that (their) grabs cannot be broken. Conversely I'd like to
prevent switching to console while the screensaver is running (for
work purposes only; some clients are a little paranoid) ... but would
like to allow switching away when it isn't locked, which is kinda
orthogonal to the other issue because in this case I *don't* want to
enable the DontVTSwitch option in the config, but have a way to force
it  on when the screensaver is active.

>  That code is a plain hack, and was written because everyone complained
> of Netscape and several other random apps dead locking (one window waiting
> for input, and another grabing input). And I remember at least at that
> time, switch to console worked (because it was not handled by xkb, so it
> worked if xkb was desactivated, as well as Ctrl+Alt+Backspace), but killing
> the locked application from a terminal, for some reason did not remove
> the grab (and depending on what was grabbed/locked, running xkill from
> the console did not work either).

Yes, quite (apologies for quoting in full, but couldn't figure out
which bits to trim without losing meaning).

I'm actually old enough to remember when this was routinely a problem,
especially the aforementioned browser (actually, there are still
occasions, with even some fairly modern apps / toolkits, but they're
thankfully pretty rare).

>  Nowadays not much people is working with this kind of logic in clients
> (grabs/locks), and most of it can be debugged with Xnest/ssh.

Again, yes, but there are cases where it's just not obvious to the
tester in normal conditions that a grab can be a problem. In real
life, as you observed:

>  Still, maybe something more well thought should be done? Not having it is
> almost like not being able to use ^C in a console, and we all know we hate
> programs that trap/ignore ^C...

Much better description / explanation than my own, thanks!

I think this is something that needs to be possible, one way or
another, and since I don't generally have to write the sort of code
that messes with grabs and so on, I'm not too fussed personally where
it goes ;o) perhaps XKB could grow a couple new APIs? We already have
stuff for keyboard autorepeat and so on; all it takes is a function
that returns the previous state and {en,dis}ables the
(Dont)?{Zap,Switch} flags.

[ I'm hoping that compared with the prospect of further mangling XKB,
someone will suggest keeping XF86-Misc ;o) ]

>> - ajax
> Paulo
Bill