• You are here :
• home
• Java Glossary
• Student Projects
• Menu and Keystroke Configurator
•  

Introduction

I propose imposing a standard on them too, and implementing it first as part of Java, or as part of Linux KDE to leapfrog past Windows in ease of use. The beauty of my idea is it does not impose any particular menu or keystroke assignment structure on anyone, not even the end user. I propose both greater order and greater freedom to easily configure things just the way you want, either globablly or on a per app basis using a standard set of tools.

I want menus globally configurable so the layout is almost the same in every program, so that FIND is on the same position in every program, and accessible with the same accelerator keystroke. I don’t want to have to configure every program separately. I want to configure how I like my menus and accelerators once and for all and be done with it.

Here is how it works.

• Function key to function mapping is global. In one place, the end user can tell the system that F8 means SAVE, and instantly all conforming apps start using F8 to mean save. I don’t have to configure each app individually, using a zillion different configuring schemes. These configurations are saved on a per-user basis so that different users of a machine can have different assignments.
• There are perhaps a dozen registered standard ways that Search and Search/Replace work. I can configure globally which scheme I prefer. I can plug in yet another one from a third party if none of the standard ones are suitable.
• I can reconfigure the Ctrl-C, Ctrl-X, and Ctrl-V keys so that they will be convenient for one-handed use on keyboard layouts other than the standard QWERTY.
• The menu structure and accelerator keys are fully user-configurable in a completely standard way. You can reorder the menus, or remove items from them you don’t want to use. This is handled by an intelligent merging of global and app defaults.
• The application programmer does not hard code in particular keystrokes or menu item positions. He specifies only standard function names. If he has some special keystroke function key needs not covered by the standard set, he gives them configurable names, and configured by the same utility.
• Standard functions would include those on the Sun keycaps:
  Help
  Stop
  Props
  Front
  Open
  Find
  Again
  Undo
  Copy
  Paste
  Cut
  plus others commonly found in apps such as:
  Help
  Open
  save
  Save All
  Close
  Close All
  New
  Print
  Search
  Search Back
  Replace
  Replace Back
  Calculate
  Exit
  Undo
  Cut
  Copy
  Paste
  Go To
  Bookmark
  Font
  Upper Case
  Lower Case
  Book Title Case
  Validate
  Configure
  Tile
  Tile Vertical
  Tile Horizontal
  Cascade
  Horizontal Split
  Vertical Split
  I would expect this list to have hundreds of items by the time you were done.
• Normally menu items would be named in a standard way to match the function names.
• Each app does the analogous thing for that command, not necessarily the exact same thing, e. g. VALIDATE might spell check in a word processor, and check HTML syntax is a validator.
• There are perhaps a dozen different scrolling schemes registered. The end user, can globally, in one place, configure which one he likes best and all conforming apps instantly start using it. If he does not like any of them, he can buy a plug-in replacement from some third party and configure that.
• The help file mechanism automatically displays the current function key assignment, menu, and accelerators as well as the function name when discussing various functions.
• The global configurator lets you print a compact cheat sheet for any app of the function keys supported, or the fully expanded menu structure.
• Similarly, the generated menus have an automatically generated menu item under help called "Keys" It displays a cheat sheet showing you all the current keystroke accelerators (less the ones discribed directly on the menus.) and their function and hover help.

Implementation

Global.PossibleFunctions

• The group that writes the automenu code and who define the official common functions. This would include functions that no currently installed app is using. You could still place these functions on your global menus in preparation for installing apps that use them. This is the preferred source. This encourages application developers to use common terminology for similar functionality. The compilers of this list need both names and definitions of what are appropriate uses for that function. You can make up fine distinctions between synonyms, e.g. exec and launch.
• A list of all functions that two or more apps just happen to be using.
• A list of all functions in all apps currently installed.

App.PossibleFunctions

Global.KeystrokeAssociations

App.KeystrokeAssociations

Global.MenuAssociations

Your globally specified preferred default menu structure, describes menu structure, Alt-style keystroke accelerators, and tooltip (bubble/hover) help. There is only one such file per user.

app is a magic keyword that tells where you want the app specific menu commands to squeeze in. Similarly app/ shows where you want the app specific stuff to squeeze in on the menu bar.

This will be merged with the list of supported app functions and the MenuAssociation overrides for the apps to create the actual menu. It is thus not an error to specify function that the app does not support.

The symbols =, & and / are permitted in the tooltip help. & has reserved meaning in the menu to specify the accelerator key.

The app itself still has the ability to hide and reveal menu items, using only their function names. It would not usually dynamically build a menu.

App.MenuDefaults

App.MenuAssociations

Internationalisation

Let us assume we want to support French, as well. The .MenuAssociations file and .KeystrokeAssociations files would be written entirely in French. The .PossibleFunctions files would be extended like this:

Tools

The tools to manipulate these files would be fully generic. The end user thus has only one configuring tool to learn, not one per app. You could also manipulate them with a text editor very easily.

The tools to modify the .PossibleFunctions files would not normally be employed by end users.

Tools would have a way of restoring you to a default factory default.

Because the file formats are so simple, it would a trivial matter to write a set of tools, with any degree of whiz-bang you wanted.

The tools warn you of conflicts between global and local settings and help you resolve them. They also detect accelerator conflicts. They would remove ordering errors, collecting together duplicate entries for the same menu column. They would warn you when you had inaccessible functions, or a keystroke or menu item associated with more than one function.

Note that the scheme can also specify 3 or even 4 level menus. These may be implemented as multiple toolbars for very large menus. The run-time engine itself would be quite robust. It would carry on no matter what a mess the configuration files were in.

Using the Scheme From Java

This is considerably simpler than building the menus item by item programmatically, and of course much more flexible.

Security Issues

There are a ton of little files to manage, one set for each user for each app. You want to be able to borrow configuration files with read-only access from other users. I have not tackled the issue of how you would name all these files to track them. You also need master factory default files and master default files for various languages. A user might even want to maintain some alternates for a given app, e.g. a stripped down version where it is easier to find stuff, and a full version.

Loose Ends

It may be difficult to remap keys like Ctrl-C, Ctrl-V and Ctrl-X which may be handled specially.

I have not described how pluggable search/replace algorithms could work that would be sufficiently general to work in a spreadsheet, database or word processing program. It would not directly touch data. It would be more of a state machine that did its work via methods of a delegate object passed to it.

I have not described how you would configure the pluggable scrolling algorithm, or define the various mouse and keystroke options to control it. This might be a class with a few replacement components for some of the scrollable AWT/Swing components, such as TextArea.

An app may regenerate the menu from scratch during its lifetime. This would allow it to have more than one menu structure, e.g. for different phases of the app. It would also allow the app to manipulate the configuring text files directly, usually to select from one of a set of canned configurations, e.g. Brief vs Epsilon vs CUA emulation.

Should there be so many separate files, or should they be combined into fewer? The advantage of separate files are:

1. Simpler tools (which might encourage an earlier implementation).
2. Fine control of read/write access using the file system.
3. More robust if people start manually editing it since the format is simpler, and damage to a file is confined to one file.
4. It is easier to add new languages, just add new files. There is no need to merge the data.
5. RAM usage is slightly more efficient since you never load data, for other languages, you don’t currently use.

1. greater speed
2. fewer files to manage manually.
3. Less confusion trying to guess which files are the ones you manually want to configure or view.

How should it come pre-configured out the box? I would hope there would develop some named schools of thought on that, and you could try the entire configuration suite with a single tool menu change to get a reasonably pleasing starting point before you did your fine tuning.

I find I cannot type without visual feedback. Secret passwords you type blind drive me nuts. As soon as the feedback disappears I go numb and just cannot type worth a bean. So, I would like the hiddenness of passwords to be configurable. I want them visible when I type. The CIA has no interest in me. I have heard there are ways of doing them so that snoops have great difficultly picking up the monitor radiation, but they are still visible.

Key bindings really needs to happen globally, including non-Java apps, so perhaps it makes no sense to try for a Java-only implementation, other than as a proof of concept. The application programmer’s interface should allow for the possibility this scheme will later be implemented at the OS rather than the Java level. It should work through methods, rather than playing with configuration files directly.

There also needs to be mechanisms for particular applications to request that they get no translation of keystrokes (or a particular one) and to query what those translations currently are.

Whatever mechanism is used, it must live in the privileged sphere, requiring user ok. Remapping the spacebar to Undo would drive many people round the bend!

What Is Important?

1. The user should have an easy way to move a menu item to a consistent place on every app.
2. The user should have an easy way to change the accelerators in all programs so they are consistent.
3. The user should have a way to override my general menu/accelerator scheme for a particular app, including the menu items that occur only in it and nowhere else.
4. Apps should work whether the user configures all the menu items or not. The user should just have to configure the menu items he finds irksome, not the whole thing. Individual Apps should provide a default menu structure. There should be default general menu structure.

Summary

I think acceptance would be much greater if this if implementing this were more of a team effort.

Happily, Sun (Hans.Muller@Eng.Sun.COM and Scott.Violet@Eng.Sun.COM) has already started some

David Alex Lamb of Queen’s Univerity in Kingston Ontario Canada has been doing some work on the problem. he suggests a scheme of search path of files and resources to find the menu and keystroke accelerator configuration information…

The KDE people are working on an implementation for Linux. Perhaps other OSes will follow their pattern, and eventually Java will have a platform-independent hook for this in-future-common OS feature.

	You can get the freshest copy of this page from:	or possibly from your local J: drive (Java virtual drive/mindprod.com website mirror)
	http://mindprod.com/project/menuconfigurator.html	J:\mindprod\project\menuconfigurator.html
	Please email your feedback for publication, errors, omissions, typos, formatting errors, ambiguities, unclear wording, broken/redirected link reports, suggestions to improve this page or comments to Roedy Green :
	Canadian Mind Products
	mindprod.com IP:[65.110.21.43]
view Blog	Your face IP:[38.107.191.107]
Feedback	You are visitor number 7,186.