Re: Toplevel keybindings

On Fri, Feb 07, 2003 at 04:46:58PM +1300, Mark McLoughlin wrote: 
> 	Yeah, I know - I don't expect the way its currently done to be the way
> we do it in the end, it was just a way of giving the thing a go. I only
> really see a few possible solutions:
> 	1) As you suggest, we move some of these keybindings configuration to a
> more central place and any window manager can pick up on that.
> 	2) We come up with a ClientMessage protocol for the panel so that
> window managers who already have keybindings for these types of things
> could bind these keys and drive the panel with the protocol.
> 	3) Give up, and say "If any window manager wants to work with this,
> someone needs to send me a patch that will detect that that WM is
> running and figure out the keybindings for that WM".
> 	I think (1) is the best plan. (2) just adds unneccessary complexity
> IMHO, it places the burden of interpreting what the equivalent panel
> operation for a given keybinding is and I doubt we could come up with a
> spec that would give use GNOME/KDE interop. (3) is what we have at the
> moment - not just in the panel, but in the keybindings capplet - and
> isn't a good idea for obvious reasons.

I would prefer simply having separate gconf keys for panel and
metacity here, though they may happen to default to the same values.
I'm generally uncomfortable with making metacity read /desktop/gnome
keys (and if I'm uncomfortable with metacity doing that, imagine all
the WMs that don't even link to gconf).

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.

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.


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