Re: 1.3a1
Re: 1.3a1
- Subject: Re: 1.3a1
- From: Mick Mueck <email@hidden>
- Date: Wed, 21 Nov 2007 08:42:25 -0500
In my experiences using (mostly CAD) X11-based programs there are many
programs that independently make use of the left and right versions of
Shift, Control, Alt and Meta. Unfortunately I only have access to a
17" MacBook Pro for the foreseeable future so I can't test if Alt_R+s
is broken in Textedit because Apple chose to put a stinking Enter key
in that place for some lousy reason (I've NEVER used that key).
However, if you read the original bug report I posted you'll see that
ALL pairs of modifier keys (Shift, Control, Meta) were reading only as
their Left version under Tiger, and despite the right modifier keys
now fixed to correctly read under Leopard (as Shift_R, Control_R,
Meta_R) I don't see that anything else regarding the right modifier
key's usage that became broken in any Mac application i.e. that change
proved to be fully backward compatible. It looks like it's all what's
in a name: Mode_Switch vs Alt_L/R.
Darn shame - I wish Apple did the 'right' thing with the 'right'
modifier keys in the first place (especially NOT making the Alt keys
inherently generic i.e. no L/R at all) and we wouldn't necessarily be
in this mess in the first place.
So if indeed every Mac program out there (including MS Office etc.) is
now broken with regards to the right-side Alt/Option/Mode_Switch key
then that's disappointing and I guess I inadvertently lost track that
I was affecting stuff on the Mac side vs the X11 side. Funny thing is
that I haven't heard the expected mighty outcry from the Mac world
that their world broke in this regard.
Is it easy to change 'Mode_Switch' into Alt_L & Alt_R only for the X11
environment and keep both worlds happy?
Mick.
On Nov 21, 2007, at 2:03 AM, Martin Costabel wrote:
I guess this is the core of the dispute that we are are having: What
do we want the keys in X11 to be consistent with? One wish is to
have them consistent with non-X11 Apple apps and the other wish is
to have them consistent with non-Apple X11 programs. We cannot have
both.
As an occasional X11 user (nowadays; I used to use it much more
regularly) I am in the first camp: If I have to type Alt-s to get a
certain letter in TextEdit or in TeXshop or Carbon Emacs, then I
want Alt-s to produce this same letter also in nedit or xemacs. And
this means Alt->Mode_switch.
This first wish is one that can be fulfilled, because the keyboard
is, after all, the same whether used with X11 or not.
OTOH, the second wish of being consistent with X11 programs on other
machines can only very incompletely be satisfied, because those
other machines usually have a lot more keys then Apple keyboards.
--
Martin
On Nov 20, 2007, at 7:39 PM, Mick Mueck wrote:
I was the (ir)responsible person for this change - while beta
testing Leopard I noticed both Alt keys were mapped to Mode_Switch.
I checked several other unix/Linux keyboards and those keys
consistently came up as Alt_L & Alt_R so I put in a request to
change them to be consistent with everything else (that I tried).
One of the reasons I submitted this bug was that software I was
using was having issues with the Alt keys. Interestingly, Apple
only changed one of the Alt keys, which I thought was kind of
weird. I let them know about that, but nothing ever came of it. So
maybe Xemacs now has some issues. Maybe the Xemacs guys just worked
with what they had available to them in a Mac keyboard. That
doesn't mean to say both Alt keys coming up as 'Mode_Switch' was
right in the first place...
Here's my original bug report:
From within an xterm in X11 run the key event viewer /usr/X11R6/bin/
xev and you can see that some of the keys (on my white Apple
keyboard which has a numeric pad to the right) are not correctly
being identified. The main culprits are the shift, control, option/
alt and command keys on either side of the space bar. BOTH shift
keys read as 'Shift_L' instead of the usual 'Shift_L' & 'Shift_R'
on every other *nix system. Same goes with the control keys (the
right side key reads as Control_L instead of Control_R), and for
the command keys (the right side key reads as Meta_L instead of
Meta_R). The option/alt keys either side of the space bar are just
weird - they both read as 'Mode_Switch' instead of the usual
'Alt_L' and 'Alt_R'.
I'm having problems with some of my keyboard bindings within custom
x-windows applications running under X11 and I believe these
incorrect key identifications are part or all of the problem.
Mick.
On Nov 20, 2007, at 4:21 PM, Martin Costabel wrote:
Artemio Gonzalez Lopez wrote:
[]
harmless. In any case, with Tiger's X11 I didn't have either the
warnings nor the impossibility of typing characters like "\" (on a
Spanish keyboard), so there should be a way of getting rid of both.
You are right, on Tiger already Alt was xmodmapped to Mode_switch.
From `xmodmap` on Tiger I get
mod1 Mode_switch (0x42), Mode_switch (0x45)
On Leopard (with Xquartz version <= 1.2a11, no ~/.Xmodmap) I see
mod1 Mode_switch (0x42), Alt_R (0x45)
I think this explains the warning: The Alt_R key is not mapped to
Mode_switch, only the Alt_L key. I would guess that a separate
Alt_R key does not exist on Apple keyboards, in any case not on
this laptop here.
So if one only wants to get rid of the warning, the remedy would be
simple: Map Alt_R to Mode_switch, too, or remove it from the mod1
modifier map.
--
Martin
_______________________________________________
Do not post admin requests to the list. They will be ignored.
X11-users mailing list (email@hidden)
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
X11-users mailing list (email@hidden)
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
X11-users mailing list (email@hidden)
This email sent to email@hidden
| References: | |
| | >Re: 1.3a1 (From: Artemio Gonzalez Lopez <email@hidden>) |
| | >Re: 1.3a1 (From: Martin Costabel <email@hidden>) |
| | >Re: 1.3a1 (From: Mick Mueck <email@hidden>) |