Re: toplevel keybindings

> hadess said
> ...
> > btw, while discussing keybindings; can we move the screenshot and run
> > dialog bindings to metacity please? There's at least one bug open
> > caused by not having all global bindings in one place, and those are
> > the last two not in metacity. The way global bindings work in X, we
> > simply need a single app to do them all.

For users of assistive technologies this isn't currently possible; ATs
(being "meta"-apps) make heavy use of global keybindings (for instance
for screenreader control), and they use at-spi API to establish them, so
at-spi-registryd issues a lot of passive keygrabs.  Many of these may
fail due to conflicts, and the clients are supposed to check this and
try alternate keybindings, etc.  It's a nasty ugly mess, but there's no
nice solution unless we really do create some sort of

When considering keybindings generally, we need to try and avoid
conflicts, and ATs are prone to them.  I have suggested that we try and
form some guidellines about suggested "reserved" modifier/keysym
combinations; ideally we'd have some blocks reserved for the WM and
'general' desktop utilities (panel, acme, etc.), some for apps, some for
accessibility and similar "meta"-utilities.   (I've suggested this
before but have had no response, but I'm sure the desirability of this
should be apparent).  If we map out reserved regions then we can
minimize conflicts and probably a lot of the bugs associated with
multiple XGrabKey clients would go away.  Alternately, we could indeed
have some keybindings daemon that would help a little (by for instance
allowing multiple clients with various levels of pre-emption, etc.); I
don't think that in this case the feature should live in metacity, but
should probably be split off.



> > Screenshot is trivial to just drop in as one of metacity's run_command
> > bindings, though this regresses the Keyboard Shortcuts control panel,
> > it could be un-regressed by adding a commands tab to that control
> > panel perhaps.
> > 
> > "open run dialog" can either have an executable that invokes it, or a
> > simple client message hack.
> When talking to Johnathan and Jody, we agreed that I would move the
> acme/keybindings stuff to the gnome-settings-daemon. That could be one
> way of solving the problem (just another key as far as this code would
> be concerned).

> -- 
> /Bastien Nocera

Bill Haneman <bill haneman sun com>

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]