Re: Unidentified subject!

[Manish Vachharajani <mvachhar vger rutgers edu>]

On Wed, 22 Jul 1998, Oskar Liljeblad wrote:
~
> A while ago there was a discussion on the gnome-gui-list about keyboard
> accelerator standards. Most people would agree that it's impossible to make
> a standard that would satisfy everyone, or even half that.
> 
> Alex Achenbach (achenbac@stud.uni-frankfurt.de) came up with an idea that
> applications should bind its commands to abstract symbols instead of "raw"
> keys. Example symbols are 'copy' (to clipboard), 'cut' (to clipboard),
> 'paste' (from clipboard), 'open', 'save', 'save as' and so on. The user
> would be able to bind keys to each command, and an API call would look up
> the key for a symbol.
> 
> However that method introduces several potential problems.
> * Can applications use any name for its symbols? Yes, but the programmer
> should make sure there isn't an equivalent symbol with another name used by
> other applications. A style guide or "command symbol repository" would help
> alot.
> * What should the default key binding for a new (uncommon) symbol be? Let
> the application choose - it doesn't matter. The API should automaticly
> assign a new key if the recommended one is already taken. The gnome
> distribution should come with reasonable defaults for common symbols
> ('open', 'save', 'save as', 'copy', 'cut', 'paste' etc).
> * What if an app has a much more important command that should use the same
> binding as a common command? These cases are hopefully rare, and I don't
> know of a simple solution yet.
> * ...
> 
> I guess this idea has already been forwarded and designed, so I'll stop
> here. Tell me if I need to explain more.
> 
> Common applications such as data editors, mail applications, file
> managers etc usually consist of one or many editable objects, and
> commands which modify or process these objects ('cut', 'copy', 'search',
> ...) or the program in general ('quit', 'help', ...). The interesting thing
> is that commands can be executed in several ways, though
> 
> * menus - "menubar menus", right-mouse root menus, and teared-off menus.
> * toolbars
> * widgets in application window - usually buttons
> * keyboard shortcuts
> * interprocess communication - in Windows this would be called Dynamic Data
> Exchange (DDE).
> 
> Now, it would be nice if the user could easily configure the menus, multiple
> toolbars and keyboard shortcuts. And it would be even nicer if the
> programmer wouldn't have to spend hours implementing it. An API could be
> created, where apps registers their commands, Gnome initializes menus,
> toolbars and keyboard shortcuts from user "rc" files, and binds
> item/button/key item to the corresponding command. The API should also
> provide dialogs for editing menus, toolbars and keyboard shortcuts.
> 
> Implementing this as an API would make every application much more dynamic,
> it would reduce code in even the most simple applications, and it would
> bring consistency among apps in this field. Of course, every application
> would have to provide default menus, and toolbars.
> 
> Good or bad idea? Tell me what you think.
> 
> Oskar Liljeblad (osk@hem.passagen.se)
> 

Personally, I think it is a good idea if the configured keys are also
themeable, such as an emacs theme, a windows theme, a mac theme, etc.  But
we shouldn't break the current interface if we don't have to.  What I
suggest is having a set of keys that cannot occur on the keyboard(Maybe
identified by a bogus modifier) map to a "virtual" keybinding that is
mapped to a real key by the users configuration.  This way apps don't need
to be rewritten and can slowly be migrated to the new key system if
everyone thinks this is a good idea.  Bear in mind that I am not
volunteering to write this :).

Manish Vachharajani
<mvachhar@vger.rutgers.edu>