Re: Orca on laptops.
- From: Bill Haneman <Bill Haneman Sun COM>
- To: Benjamin Hawkes-Lewis <bhawkeslewis googlemail com>
- Cc: Ubuntu Accessibility Mailing List <ubuntu-accessibility lists ubuntu com>, Gnome Accessibility List <gnome-accessibility-list gnome org>, Orca screen reader developers <orca-list gnome org>
- Subject: Re: Orca on laptops.
- Date: Wed, 08 Nov 2006 15:17:06 +0000
I see, you're talking about a different thing from what I was referring
to - I thought you were talking about the "CapsLock behavior" settings,
which are all latching.
What you have done, as far as I can tell, is re-map the CapsLock key to
be a different key altogether - so it's no longer CapsLock from the
Xserver or keymap point of view.
Using XKB and similar APIs we can alter an existing keymap, remapping
pretty much any key to pretty much any other keysym; similarly, there
are pieces of the XKB API that would allow us to implement almost any
behavior we want; however, this would be at the cost of complexity both
in orca and in testing/verification.
I think we should be careful to distinguish between using/adapting the
behaviors of the existing key symbols in existing keymaps, and altering
those keymaps fundamentally. In your example of re-mapping CapsLock to
"Compose", I would suggest that CapsLock no longer exists in the keymap
and so it is potentially confusing to refer to this key as "CapsLock" in
It does, however, point out the potential for using remapping to
"create" any key via remapping, even for physical keyboards that don't
include that key in their default printed key set. For instance, the
keymap alteration technique above could be used to provide AltGr on
Calum's iBook even though the default keyboard map doesn't include it,
and there is no key labelled "AltGr" on the physical keyboard. So for
instance if we decide that "right shift" should do something special in
orca, we could use remapping to assign "XK_shift_right" to any physical
key we chose. This means of course that the original use of the key in
question would no longer be available, just as in Benjamin's example the
CapsLock key no longer affects the 'ShiftLock' modifier; in effect
CapsLock ceases to be available in such a scenario.
Benjamin Hawkes-Lewis wrote:
On 11/8/06, Bill Haneman <Bill Haneman sun com> wrote:
I don't see that option in the preferences dialog - you can indeed alter
the way CapsLock works, and whether the Shift key cancels CapsLock or
not, but it seems to be a latching key in all cases, as far as I can tell.
Just tested it on my Ubuntu Edgy box, and as far I can tell you're
mistaken. In Keyboard preferences, look for the "Layout Options", then
"Compose key position". Now I have a British Thinkpad keyboard. If I
tick "Right alt is compose" then pressing [AltGr] + ['] (that's
apostrophe) then [e] outputs an e acute. But let's say I tick "Caps
Lock is Compose". Now two things happen. First Caps Lock no longer
affects capitalization. And second, it acts just like [AltGr] before.
If I press [Caps Lock] + ['] then [e], it outputs an e acute. But
pressing [Caps Lock] then ['] then [e] outputs an apostrophe then a
normal e. Doesn't that imply it is no longer latching?
gnome-accessibility-list mailing list
gnome-accessibility-list gnome org
] [Thread Prev