Re: Gnome Key Binding Standard

[famrom ran es (Guillermo S. Romero / unnamed / Familia Romero)]

>I thought I'd put up some proposal for that, just to make a start
>(I don't know any Gnome internal status of discussion on this issue);
>the following is just a draft (or "wish list") based on the
>experience with various programs and on my personal needs
>and thoughts.

OK, lets go. Thats one thing, that if well done, will get lot of adepts.

>Unfortunately, I cannot currently plan on implementing this myself
>(maybe later this year...?).

Me either. :[

Should it go in some global place, does not it?

>The main purpose of this is to suggest a basic set of keyboard
>functions; the given "possible bindings" are just examples.
>Every common binding should of course be globally configurable still.
>What's important is the abstract set itself.

Configurability is a must. Maybe a Keyboard screen should be done, similar
to that used for screensaver.
Some guy prefer other keybinding, and in some languajes the English
keybinding may be really rare, so a way to support other languajes
keybindings must be implemented, and what is better tahn "configurable", you
can configure for your wishes or create a set for all Fooland natives (BTW,
I prefer, but just "I", the English keybindings and menus, the only I
requiere is support for text in my languaje, so I can write Spanish letters
in GWP with English menus, for example).

>So here are the menu accelerators. I'd consider implementing some
>of these (especially cut/copy/paste, maybe undo/redo) in text
>entry fields as well, overriding the actual menu accelerators for
>as long as the entry field has focus.

Menus should work with Alt, do not them? (Maybe I am too much proM$ in this
situation, and my X knowledge is not perfect)

>One might even consider extending the configurability of key
>bindings beyond the scope of accelerators, eg to allow
>configuration of keyboard functions of all GTK objects,
>something like "keyboard themes" (eg wether Tab means a real
>tab character or wether it will navigate you to the next object
>if a text entry field is having focus).

Yes. Keybindings should adapt to the situation.

>This could then extend to mouse button functions (eg what to
>use as the drag button, with possible modifiers for various
>dragging modes, like move, copy, or link).

Interesting.

>Not all of the functions should be absolutely freely configurable,
>of course (eg it should avoid definition conflicts of any kind).

Well, if the thing is done in a global place, where all programs look for
its keys, global or local, there is no problem.

The Keybinding configurator app should have a place to "Configure globals"
and another to "Choose an app, and configure its locals", so the
configurator will know (and avoid) when a "collision" happens.

And what is more, if and app does not have a fuctions (search in a game,
what to search?), it will allow "pacted collision", so for example a image
app can use Prev/Next Page for Zoom.

>Also, there should be a means of detecting (and acting upon) a
>collision of an application-specific non-standard menu accelerator
>(for a non-standard function) with a user-configured common binding
>(eg user has globally bound "find" to Ctrl+H for some reason, while
>an application's default for its menu item "Display Histogram"
>is also Ctrl+H); the global configuration by the _user_ should
>always have precedence then (to avoid confusion and the risk of
>involuntarily launching the wrong function).

Why not when a new apps is installed, it registers its key requirements, and
when it is launched by the first time, it says "Ooops, keybinding collision.
Launch keybinding editor?" "Non configured keybinding. Launch keybinding
editor?" (for the case whe there is no collision, only the need to define
new keybindings for a rare/non-goblal feature).

>And finally, any Gnome key definition should be flexible enough
>to deal with old X11 style key mapping as well as the new XKB
>extensions, ie be able to handle various kinds of modifiers.
>Also, it should be possible to bind more than one key to the same
>function for the sake of being universal.

Nothing to say here, green at X.

>function	possible binding	equivalent to menu item
>(abstract)	(set by user)		(implemented by programmer)

possible (English) binding

>quit		  Ctrl+Q		File/Quit

Quit full app.
And close current doc - Ctrl+W - File/Close.

>goto		  Ctrl+L		Edit/Goto_Line...

Jump? - Ctrl+J - Edit/Jump_to_line...

Moves - Arrows - no menu, just move around.

Next/Prev Page - Next/Prev Page - no menu, just move around.

>macro_create	  Ctrl+Shift+K		Macro/Record (and finish)
>macro_replay	  Ctrl+K		Macro/Play

I think some apps use Ctrl+K...

>close window (eg Ctrl+W)	there should be a window manager close_
>				window key for this, which is sufficient
>				(it should be editable there)

close doc, not full app, like Gimp.
And why WM? If keys are gone to be in one place, why start spreading around?

GSR