there in Motif 1.0. Answer: From: ellis@osf.org Virtual Keysyms are meant to provide a consistent keyboard model for Motif applications running in a heterogeneous environment in which proprietary (i.e. vendor specific) non-Motif applications may also be running. First of all, for the sake of the rest of the readers, let's explain why this is an issue: It would be lovely if Motif's translation tables could just use the obvious keysyms predefined by X. For example, there are keysyms for XK_BackSpace, XK_Delete, XK_Left, XK_Right, etc. Shouldn't these be the ones that are used in our translations? Unfortunately, the problem is not so simple. Some specific examples: While most vendors bind XK_BackSpace to the key at the top right of the standard keyboard (often engraved with a leftwards pointing arrow), not all do. In fact, some vendors (including DEC) bind that key to XK_Delete. While most vendors bind the arrow keys to XK_Up, etc, a number of vendors (including Sun, on some servers) bind them to function key keysyms. A simplistic solution would require the use of xmodmap to change the offending bindings. That would work swell in an all Motif environment. However, OSF's goal (not always perfectly achieved) is interoperability. That is, we'd like to make sure that both Motif and non-Motif programs can happily run in the same environment. It is expected that a vendor may have a wide variety of existing X-based software that uses the keysyms as established by that vendor for specific purposes. It is expected that these applications may run at the same time as Motif-based software. Using xmodmap to change keysyms on the server side could "break" the existing applications (or at the very least their documentation) by making some keys unavailable, or by moving the location. So, we chose not to use xmodmap. By the way, though OpenLook uses a different implementation (they recompile their virtual translation tables into actual translation tables), they basically adopted the same approach, presumably for similar reasons. To work properly, the virtual keysym model we implemented depends on Xlib finding XKeysymDB installed appropriately (which standard Motif installation does). This simply defines the keysyms (not the key they are bound to). This unfortunate piece of stupidity is necessary because MIT only includes standard keysyms in keysymdef.h. It should be said that our lives would be made easier if MIT would also see fit to include registered keysyms in keysymdef.h as well. Motif applications determine how to bind virtual to actual keys by looking for either a resource or a property on the root window which describes what to do. Note that this information is on the server side, so that all applications use the same virtual bindings regardless of where they are running. Mwm will happily create the property if it finds a .motifbind file in your home directory when it starts up. (Actually, things generally work even if none of this is done, since if all else fails, the Motif toolkit chooses a virtual bindings table to use based on the identification of the server). The actual implementation of virtual keys is made possible by a hook in the Intrinsics. Undoubtably, the implementation would be simpler and cleaner if virtual key support was more directly supported by the Intrinsics. We will be exploring this possibility in the future. -- Ellis ----------------------------------------------------------------------------- END OF PART FOUR -- .........................Go Back Up