Re: Tab as completion shortcut

[Petri Heinilä <hevi lut fi>]

thristian@atdot.org wrote:
> 
> 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

I think that windows-theme and emacs-theme should be separate, because
they conflict; ctrl-a, ctrl-c and so on. 

> 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.

Yepp.

> 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*".

For teaching the keybindings are secondary. It's clearer to share
information
between users as simply menu command names eg.: "in window make
select-all", "then do
copy", "move to other window", "make paste". When user advances, he
founds the
keybindings or apply already learned input model.
> >
> > Yes, in the GIMP manual ;-).  After all, that's where Gtk+ came from ... it
> > just needs to be ported over to the Gnome manuals.

Or should they be in gtk 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.

If program knows it's keybindigs, why it cannot present list what they
are,
and also manage conflicts ?
 
> > > 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.

Definitely!
 
> 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.

Yes.

> 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".

More features:
 * Conflict management: conflicting keys definitions are shown red.
 * These bindings are under theme, that can be saved into shareable
   package. Themes might be inherited (keybinding overrride) from other
   themes.

> 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?

Rework of the Gtk! I checked the Gtk+-1.3.1 source code and found, that
the keybindings are hardcoded. 

> 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...

This is the question finding good organization to have meaningful size
categories and to support reuse of the keybindigs and find a policy
how bindings are overrided.

> 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 think these features can be embedded into this UI. Theme is the
name of the particular configuration (maybe list of themes available
added). Confilts are show bu color or icon, and some pointer by with
it conflicts.
 
> I'm still not sold on the idea of every keystroke being redefinable,
> but if it is, this UI idea might work.

If there is mechanism to redefine, why not apply it to all functions.
"If you can, does not mean you should".

-- 
email: Petri.Heinila@lut.fi
  www: http://www.lut.fi/~hevi/
  gsm: +358 40 52 77 589
  irc: hevi (IRCnet)