Re: Tab as completion shortcut

[thristian atdot org]

On Thu, Aug 17, 2000 at 01:35:42PM -0400, Michael T. Babcock wrote:
> ----- Original Message -----
> > thristian@atdot.org wrote:
> >
> > Well I wouldn't say that everything is inherited from emacs. Lots of
> > apps use common bindings from Windows too, and I believe those too come
> > from GTK+ defaults.

I think there was some mention in here of Ctrl-X, -C, -V. Well, I
don't know what those do, exactly, or how they work - I just use the X
Primary Selection. Any time I select something, I expect it to be on
the clipboard - because that is a consistent behaviour over all the
apps I use (and the odd cases, like sometimes in Mozilla, are reported
as bugs - not by me, either!)

> > However, there are situations when emacs defaults and Windows defaults
> > overlap. Take Ctrl + a for example. In emacs it positions the cursor on
> > the beginning of the line, in Windows it selects All text.

Selecting all text clobbers your clipboard. Most of the time, if you
just want to clear the box, Ctrl-U works.

I see your point, though. I'm beginning to see why "keybinding themes"
is useful (but *no* vi themes, if you value your life & sanity! :) -
the default could be GTK+ style merge of Windows and emacs, and
various distributions could change the default for their installs - so
RedHat might choose to make "Windows" the default keymap, and
YellowDog might choose "Mac". When Sun makes GNOME their default
desktop, they can make a keymap based around the funky keys on a Sun
Type 5 keyboard, and so on.

On the other hand, this leads to difficulties of: "How do I select all
the text in this window?" "Well, what are you using?" "Uh.. Linux?"
"Could you be more specific?" "Uh.. GNOME Linux thing?" "*sigh*".

> I think that we need to start assuming that users have 101/104 key keyboards
> to some degree and offering not just functioning CTRL-(x) shortcuts but

...except we've already established that not everyone has 101/104 key
keyboards. Anything outside the "main" keyboard cluster should be a
shortcut to functionality already available elsewhere. "Select All..."
might be in the Edit menu, "Move cursor to beginning of line" might be
done with a mouse-click.

Also, you might want to be binding functions to X keysyms, not to
actual keys, and then you can make global remappings with xmodmap.. on
the other hand, that's about as big and clumsy as a #define in C, so
maybe not.

> > I didn't know this - is it documented somewhere?
> > Yes, I tried it and it is indeed very nice - but I agree, it should be
> > easy to reset the default ones, they should be made global and
> > remembered across sessions and apps.
> 
> Yes, in the GIMP manual ;-).  After all, that's where Gtk+ came from ... it
> just needs to be ported over to the Gnome manuals.

Wow. OK.. /usr/doc/gimp-1.1.24/keybindings.txt tells me that if you
reassign a keybinding that's already assigned to another function, the
old mapping vanishes without even a warning... that's bad, I think.

> > Shouldn't that list be a global configuration dialog, so that I don't
> > have to edit it in each app? I.e. a common resource that apps can launch
> > when users want to edit keybindings, and not a dialog that has to be
> > reimplemented in all apps.
> 
> As per my other message ;-).

OK, yes, yes it should.

The GTK+ text widget doesn't ATM have a context menu, but I was
planning that it *should* have a context menu, and the "key-remap"
dialog should be part of the GTK+ widget code, making it available to
non-GNOME apps, too.

This functionality would also be useful in the Keyboard capplet (P.S.
we need to find a better name than "capplet" for actual dialog text -
"capplet" means nothing)

I'm thinking of a layout something like this: a tree widget on the
left labelled "Scope". At the root is "Global" - these would be things
like the Panel's keybindings. Inside that is an entry for each GNOME
app installed, and each app can define sub-scopes if it wants. Look at
the "Sound Events" page of the Sound control panel to see what I mean.

The Scope would act much like variable scope in a programming
language, but not quite: a particular function should only appear
*once* in the hierarchy (can't define Quit to be something globally,
and something else in, say, Gnumeric), but the same keybinding can be
re-used, so keybindings for "Justify Text" or "Print" don't get in the
way of choosing convenient controls for Gnibbles or GnomeQuake.

So the tree looks something like:

Global
 v- Buttons, Boxes, Lists, and Controls
 |   v- Text entry box
 |   |   +- Filename entry box
 |   v- List box
 |   |   +- Multiple-selection listbox
 |   |   +- Hierarchy list
 |   +- Tabbed window
 |   +- Scrollbar
 |   +- Checkbox
 |   +- Radio button
 v- Common Application Functions
 |   +- File handling
 |   +- Editing
 v- Abiword
 |   +- Print Preview
 v- Gnumeric
 |   +- Chart Editing
 +- Gnibbles
 >- Window Manager

..and so on.

When you choose an item in the tree, the right hand side of the dialog
gives a single-selection list with columns "Name", "Description", and
"Keystroke". We should allow multiple keycombos per function, so they
should be listed like "Control-A, Home, Meta-^". There should also be
a drop-down list labelled "Presets", and "Save As..." and "Delete"
right next door. This theme would only save and restore bindings in
the current list. Below the list would be "Add keystroke...", which
pops up a little box saying "Press the new keystroke or Escape to
cancel" (since we probably should never allow bindins Escape or Enter
to an unusual function), "Delete keystroke", which pops up a list of
keystrokes bound to the current command and lets you select one,
"Clear keystrokes", and "Restore default".

This would be an alternative view into the global keybindings database
that GNOME would be storing in order to keep track of menu-made
keybindings.

Problems I can see with this approach:

1 Rework every GNOME app to get its keystrokes from a database instead
  of stored locally?
2 The tree system above uses the tree for both depiction of scope, and
  for categorisation. This is bad, as something like Global will have
  a bazillion commands - actual global commands as *well* as commands
  we don't want overridden by individual apps...
3 It would be most useful to be able to combine keystroke themes (so
  you could make your text widget work like Emacs and Windows
  simultaneously) but that needs extra UI - and even *more* UI for
  dealing with keystroke clashes.

I just realised problem 2 can be helped by making the tree go more
like:

Global
 >- Buttons, Boxes, Lists, and Controls
 v- Applications
 |   +- File handling
 |   +- Editing
 |   v- Abiword
 |   |   +- Print Preview
 |   v- Gnumeric
 |       +- Chart Editing
 >- Games
 >- Window Manager

...but that just shifts scope difficulties to Applications and Games.

Comments? Ideas?

I'm still not sold on the idea of every keystroke being redefinable,
but if it is, this UI idea might work.

-- 
,------------------------------------------------- ------ ---- -- -  -   -
| Screwtape | Reply-To: is munged on Usenet | members.xoom.com/thristian
|--------------------------------------------- ---- ---- --- -- - - -  -  
|
| "Everyone needs to hang on tight, just to keep from being thrown to the wolves"
|