Re: Tab as completion shortcut

[thristian atdot org]

On Fri, Aug 18, 2000 at 02:35:27PM +0300, Petri Heinilä wrote:
> 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. 

Yes - a Windows theme and an emacs theme would be Good, but the
current GTK+ bindings aren't either one.

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

Hmm.. I suppose that's true.

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

Heh - who reads 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 ?

It can, but in the middle of a popped-up menu is *not* the time or
place for popping up dialogs. Menus are for short, quick use - not for
extended manipulation. Things like direct-manipulation of menu
entries (Win98 Start menu) or menu entries having context menus (GNOME
foot menu), these are Evil. No other menu in each respective GUI does
such things. I'd reccommend that Foot menu contain just (a) the
toplevel application hierarchy, (b) an entry called Edit This Menu,,,
that starts the menu-editor (which has drag&drop and all sorts of GUI
goodness - including "Make drawer" and "Add Application Launcher to
Desktop" and so on, and (c) one last submenu that contains all the
other stuff currently in the top-level menu, like About GNOME and
About the Panel.

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

...with no forced GNOME dependencies, mind you - I remember reading
the furore on /. about GtkHTML.

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

In my setup, there's two kinds of conflicting keystrokes - two (or
more) identical keybindings in the same scope (which is *bad*), for
which a warning dialog *should* be presented, and a keybinding in a
narrow scope that conflicts with a keybinding in a wider scope (which
is just fine).

For the first case, the dialog should have "Replace" and "Cancel"
buttoms, and an appropriate message. For the second, the buttons
should be "Replace", "Override", and "Cancel", and also a "Do not show
this dialog again" checkbox. The text should explain that there's a
conflict with a keystroke in a higher scope.

Actually, there's a third possibility: the keybinding conflicts with
a keybinding in a lower scope.. should this make a warning?

At any rate, the way to turn on the dialog if you've Not Shown It
Again woyld be a "Warn about overriding higher-level keystrokes"
checkbox on the Keystroke-editor dialog or something... and the
adjective "higher-level" needs to be replaced, but with what, I don't
know.

>  * These bindings are under theme, that can be saved into shareable
>    package. Themes might be inherited (keybinding overrride) from other
>    themes.

How do you say "this inherits from that"? Inheritance is *another*
complex concept (well, not *that* complex, but not often encountered -
at least in the CS sense, and I've seen how long it takes first-year
CS students to get their heads around it) and it would probably need a
large, Dia-style workspace to conveniently and efficiently manipulate
inheritances properly. That might be OK if we were writing a top-level
application, but we're talking about a couple of widgets in a dialog
from the least significant entry in a context menu of a simple widget
in a random dialog hidden at arbitary depth in a real program. I just
don't think there's *room* - physically or conceptually - for anything
larger or more complex than a drop-down list.

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

Oooh.. unless already planned for GTK+ 1.4, this might wind up in
GTK+1.6 or 2.0, and hence GNOME 2.2 or 3... *loooong* time away.

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

I always appreciated MS Word's abstraction of keybindings, toolbars
and menus, where it just had a central command list and you could add
a given command to a menu, a toolbar, or give it a keystroke, all from
the one dialog..

-- 
,------------------------------------------------- ------ ---- -- -  -   -
| Screwtape | Reply-To: is munged on Usenet | members.xoom.com/thristian
|--------------------------------------------- ---- ---- --- -- - - -  -  
|
| Fried eye car nelpew.
|