Re: Tab as completion shortcut



Considering that every application eventually wants to offer the user the
ability to redefine some previously unthought-of keystroke, just have
applications 'register' those keystrokes in their gnome-conf files in a
standard way.  Then have the capplet pass through your application conf
files for those key=value statements.

That said, organise them by standard and application-specific.

-- system wide
 - file open
 - file save
 - copy
 - cut
 - paste
 - select all
 - edit preferences
 - see properties
 - etc.  (in more of a hierarchy, if you wish)
-- application specific
 - gnibbles
   * left
   * right
   * up
   * down
   * suicide :-)
 - gnorpm
... etc.

----- Original Message -----
From: <thristian@atdot.org>


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






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