Hi Benjamin: 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 our discussions. 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. Best regards, Bill > Benjamin Hawkes-Lewis wrote: > On 11/8/06, Bill Haneman <[EMAIL PROTECTED]> 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? > > -- > Benjamin Hawkes-Lewis > _______________________________________________ > gnome-accessibility-list mailing list > gnome-accessibility-list@gnome.org > http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list > _______________________________________________ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
