Re: Tab as completion shortcut



On Thu, Aug 17, 2000 at 04:16:21PM +0200, Christian Rose wrote:
> Petri Heinilä wrote:
> > I think same kind mechanism should apply for keyboard input (or other
> > input
> > devices as well). There would be profiles like "emacs", "vi" or
> > "windows".

I use Vim exclusively. I find myself going through the vi motions even
in Netscape and sometimes in Windows. But I do *not* want anything in
GNOME to have a "vi" mode. For one, if a newbie gets himself into vi
mode accidentally ("Oooh.. I can make all my text widgets be `six'..
I wonder what that does?") they will go through *hell*. Secondly, the
amount of abstraction that the API would have to undergo to generalise
between a fundamentally modeful and a fundamentally modeless interface
just *scares* me.

Also, with few exceptions, Linux desktops *are* developing a
consistent unified keymap - the emacs keymap. Basic, simple functions
like "beginning of line", "end of line", "delete to end", "clear line"
work consistently and naturally across bash, Netscape, and GTK+
widgets - and even in Vim, a little.

> I agree. Since not everybody could agree on, or feel comfortable with, a
> particular keyboard shortcut, I think it's a great idea to make it
> user-definable (probably by a section in the control panel or so). That
> configurability doesn't take away the need for a sensible default,
> however.

Some of you may remember when we had David "MacKiDo" Avery subscribed
to the list, whose mantra was "Choice Is Bad". This attitude made him
quite unpopular, as you can imagine, but he did have a point. The
Macintosh, in my experience, has one of the nicest keyboard interfaces
I know, because the user gets no options in choice of keybinding -
anything you learn once you can use on any Macintosh. I've recently
been discovering the wide range of GNOME apps that listen to Ctrl-W
for Close Window and Ctrl-Q for Quit.. well, for Exit, technically,
but I think of it as Quit - and this standardisation is immensely
pleasing to me. I know we're not proposing each app have its own
keybindings, but portability between installations is useful, too..

Also note that GTK+ already has a very cool way of specifying
keybindings for menu-items: hover the mouse over the menu-item you
want, and press the keycombo you want. Backspace removes any
keybinding. I don't know if there's a key for "restore default". Not
enough GTK+ apps remember their keybindings from session to session -
if we get GNOME Human Interface Guidelines, I would suggest this is a
"MUST" (as the RFCs say) feature. 

But the editing combos aren't in menus, you say? Well, they should be
in the context menu - at least the simple ones (Paste, Select All,
Undo, Redo, etc), maybe the more esoteric keybindings (Move Cursor To
Beginning Of Line..) could be reached with a "Other Actions..." menu
entry that loads a list of possible functions (look at "man readline"
for the sort of functions we might want). This function list is
supposedly to let people access functions that they don't have bound,
(so you can double-click, say, on the "Move cursor to beginning of
line" command, and the dialog closes and the cursor is moved to the
beginning of the line), but also lets people edit keybindings for all
these things.

The downsides I can think of are that the "live" key remapping has
serious problems from a UI point of view: It's not obvious that
bindings can be changed, it's not obvious how, it's not obvious that
they can be cleared, it's not obvious how they can be restored.

One other thing.. I don't know if this is already the case, but if
someone changes a "system wide" menu keybinding (like, say,
Preferences or Exit), that should be reflected in all apps..

-- 
,------------------------------------------------- ------ ---- -- -  -   -
| Screwtape | Reply-To: is munged on Usenet | members.xoom.com/thristian
|--------------------------------------------- ---- ---- --- -- - - -  -  
|
| My rabbit is, decigram for decigram, the cutest creature on earth.
|





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