rlh2@ukc.ac.uk (Richard Hesketh) (07/31/90)
We use here a varied collection of NCD X terminals, DEC and Sun workstations. It has been noticed that using toolkit programs that require text entry via the Athena Text widget that what *we* think the <Meta> key is .. i.e. the key immediately to the left of the spacebar .. does not work. I assume that this is because the keyboard generates a different KeySym (Alt in the case of the NCD's and something else for DEC's "Compose" key). Now the rub comes because it confuses our users who are used to thinking that the key to the left of the space bar is the "Meta" key for window manager functions. It seems obvious to me that we need to either use xmodmap to change what KeySyms are generated for these different displays to generate the <Meta> KeySym required by the Text Widget; Or to provide an #augment or #override translation line for Text widgets. I prefer the xmodmap approach, however, I was wondering if anybody else has coped with this problem? What is your solution? I'd be grateful for any answers. Thanks, Richard Hesketh : @nsfnet-relay.ac.uk:rlh2@ukc.ac.uk : rlh2@ukc.ac.uk ..!mcsun!ukc!rlh2 --- Computing Lab., University of Kent at Canterbury, Canterbury, Kent, CT2 7NF, United Kingdom. Tel: +44 227 764000 ext 7620/3682
emv@math.lsa.umich.edu (Edward Vielmetti) (07/31/90)
In article <5213@harrier.ukc.ac.uk> rlh2@ukc.ac.uk (Richard Hesketh) writes:
We use here a varied collection of NCD X terminals, DEC and Sun workstations.
It has been noticed that using toolkit programs that require text entry
via the Athena Text widget that what *we* think the <Meta> key is ..
i.e. the key immediately to the left of the spacebar .. does not work.
I was wondering what was causing that behavior (sitting in front of
a Dec 5000's keyboard (UWS 4.0) running applications from a Sun 4
(X11R4). Any fix would be welcomed.
--Ed
Edward Vielmetti, U of Michigan math dept <emv@math.lsa.umich.edu>john@acorn.co.uk (John Bowler) (07/31/90)
In article <5213@harrier.ukc.ac.uk> rlh2@ukc.ac.uk (Richard Hesketh) writes: >We use here a varied collection of NCD X terminals, DEC and Sun workstations. >It has been noticed that using toolkit programs that require text entry >via the Athena Text widget that what *we* think the <Meta> key is .. >i.e. the key immediately to the left of the spacebar .. does not work. This is one of the things which we noticed when porting R4 to our hardware. There was a change (bug fix?) between R3 and R4 in the Athena Widgets; to make them match the documentation (if I remember correctly). >I assume that this is because the keyboard generates a different KeySym >(Alt in the case of the NCD's and something else for DEC's "Compose" key). >Now the rub comes because it confuses our users who are used to thinking >that the key to the left of the space bar is the "Meta" key for window >manager functions. It gets worse if you have a window manager (eg) which looks for ``Alt'' and an application (xedit for example) which looks for ``Meta'' - then you need both. >It seems obvious to me that we need to either use xmodmap to change what >KeySyms are generated for these different displays to generate the ><Meta> KeySym required by the Text Widget; Or to provide >an #augment or #override translation line for Text widgets. > >I prefer the xmodmap approach, however, I was wondering if anybody else >has coped with this problem? What is your solution? I'd be grateful >for any answers. Our solution is to associate both keysyms with the key by default; the binding of the two keys in question is:- Modifier Keysyms -------- ------- Mod1 Alt_L Meta_L Mode_switch Mod1 Alt_R Meta_R Mode_switch This *almost* works. Certainly the Alt+Meta bit works - because applications look for the key code associated with a particular keysym, so it doesn't matter whether they go after `Alt' or `Meta'. Unfortunately the Mode_switch bit only partially works. The idea is to make the alternate (ISO-Latin-n) graphics symbols on the various letter keys actually produce those characters in the Athena text widget (when run with a suitable font). Unfortunately there is contention here for the modifier. The text widget uses some combinations of Meta+<letter> which therefore obscure the relevant symbols, for example:- Meta<Key>Z: scroll-one-line-down() can obscure the binding of guillemotleft to the left most bottom row key as specified by many national keyboard standards. (Ok, I know this key is W on a French keyboard and Y on a German one, but other keys are affected similarly on those keyboards). The basic problem is that the shift key designed (by the keyboard designer) to produce extra graphics symbols is being used by the system (Athena Widgets in this case; but this just comes from the older emacs usage) to access editing functionality. Given that there aren't any other shift keys available for this purpose (Control is already heavily used) the problem is difficult to avoid. Overriding the Text Widget translations is viable, but has the effect of producing another non-standard, probably undocumented, set of conventions. The OSF solution; of using bindings defined on a per-server basis, is more viable because it does at least allow those editing keys which are available on a particular server to be used. John Bowler (jbowler@acorn.co.uk)
meo@rsiatl.UUCP (Miles ONeal) (08/02/90)
At Sales Tech, we had the startup stuff check the node name-
if it was the oddball (Sun386i's in our case), we xmodmap'd.
It wasn't Meta, but it was a similar situation.
-Miles
Miles O'Neal
{uunet | emory}!rsiatl!meo (home)
meo@sware.com (work)
{uunet | emory}!sware!meo (work)