Willie Walker writes: > The concern regarding XKB/xmodmap is worth noting. I believe xmodmap is > an acceptable XKB client (if I recall correctly, xmodmap has code in it > to work with XKB), however, and it should ship on all platforms we care > about. If we come across a platform that causes us concern with > xmodmap, we can stir up XKB API usage from Python if we need to - if it > offers the "go back to the way it was when I die" behavior, that's a > bonus. That, however, is primarily an implementation decision within > Orca. > Bill, Will: Is there something we should add to our FSGA Keyboard spec about this?
> If the majority > of users are adamant about obtaining normal Caps Lock behavior via some > other gesture on the same key (e.g., a quick double press of Caps Lock), > well, we'll need to think about it. If users say that kind of thing is > a "nice to have", however, I'd prefer we note it as a future enhancement > and not over engineer at this point. > Regret to say it's important. What gesture might be acceptable is certainly worth discussion. I would not hazzard a strong statement myself. I'm of the opinion people would accept something possibly simpler such as Shift+CapsLock, or Ctrl+CapsLock. I'm guessing that's simpler than a double CapsLock tap, but I certainly don't really know that. Wonder what others think? > I'd also like everyone to keep the other bigger picture in mind: even > with our generous community members helping, we're a small team and each > feature (even the hours spent discussing the feature) has an opportunity > cost. For example, I'm engaged in this discussion right now versus > focusing on Firefox accessibility. Mike is engaged in documenting this > discussion instead of focusing on other important aspects of the Orca > design. Bill is engaged in this discussion instead of focusing on high > priority AT-SPI implementation problems. > > We need to reach a point where we have the courage to make a decision > and move on. I think we're almost there. > > So...is the proposed solution acceptable? Another way to look at it > would be this: assume I was smart enough to remember the xmodmap > solution when Mike was beating on me for Caps Lock last year. Caps Lock > would work as described above and Caps Lock would be the default Orca > modifier. Would that be acceptable to you? > Will, I wouldn't get rid of Insert, I'd duplicate Insert with CapsLock. There's too much user history around this. Also, Insert on the numeric keypad provides a one-handed solution. Janina > Will > > On Thu, 2006-11-09 at 15:21 +0000, Bill Haneman wrote: > > Hi Will; > > > > I think this is basically what I and other contributors meant by > > "remapping" CapsLock. I would consider using the XKB client API for > > this instead, in case xmodmap is not in the path (anyhow, I think XKB is > > the preferred interface for modifying the keyboard map on XKB-aware > > systems). Some of the XKB client settings also allow clients to tell > > the Xserver to "reset" to defaults when the client exist, which would > > make the restoration of 'normal' CapsLock behavior robust even if orca > > were killed with Ctrl-C or crashed - not sure if the key-remapping APIs > > are among those - perhaps you do, since I recall you having participated > > in the development of XKB :smile: > > > > Bill > > > > Willie Walker wrote: > > > Hi All: > > > > > > I've been watching mostly from the sidelines because I wanted to hear > > > from our users before injecting my opinions and such (except mainly for > > > expressing the opinion that I want to hear from our users ;-)). What > > > I'm hearing is that using the Caps_Lock key as the Orca "modifier key" > > > is an absolute requirement and we should do what we can to make it > > > happen. > > > > > > I believe the main problem with the Caps_Lock key is not if we can use > > > it as the Orca modifier or not. We can. The main problem, however, is > > > that once the user touches the Caps_Lock key, the Lock *modifier* will > > > still be locked and unlocked. This presents a serious usability > > > problem. > > > > > > I did little experimenting, and I believe we have a simple solution for > > > this problem. Having worked on the X Window System since the late > > > 1980's, I'm not sure why this didn't come to me earlier. The X Windows > > > System offers a command called "xmodmap" that allows you to muck with > > > modifier mappings. For example, the following command will prevent the > > > Caps_Lock key from acting as a locking key: > > > > > > xmodmap -e "clear Lock" > > > > > > And, for those that want their Caps_Lock behavior back, the following > > > command restores it: > > > > > > xmodmap -e "add Lock = Caps_Lock" > > > > > > We can use this to solve our problem. When Orca starts up, it can check > > > the orcaModifierKeys setting. If the list includes Caps_Lock, Orca can > > > execute the magic xmodmap command to clear its locking/unlocking > > > behavior. > > > > > > The only issue here is cleanliness and restoring the xmodmap to what it > > > was before Orca changed it. I'm not sure this is a big concern. The > > > reason is that I assume Orca is going to be something that the user runs > > > all the time to access their Desktop. > > > > > > Attached is a patch to orca.py from GNOME CVS HEAD for anyone wants to > > > play around with this. You'll need to apply this patch (patch -p0 < > > > caplock.patch) and you'll need to add/edit the following line to your > > > ~/.orca/user-settings.py (can get blown away) or your > > > ~/.orca/orca-customizations.py (will not get blown away) file: > > > > > > orca.settings.orcaModifierKeys = ['Caps_Lock'] > > > > > > Btw, you can also do the following if you want both Insert and Caps_Lock > > > as the Orca modifier key: > > > > > > orca.settings.orcaModifierKeys = ['Caps_Lock', 'Insert', 'KP_Insert'] > > > > > > Let me know if this works for you. If it does, we can make it a > > > permanent part of Orca. > > > > > > Will > > > > > > On Thu, 2006-11-09 at 09:48 +0000, Bill Haneman wrote: > > > > > >> Makes sense, with the caveat that if we remap CapsLock to achieve this > > >> (as we probably must, to avoid the latching behavior), then the end > > >> user will no longer be able to use CapsLock in the "normal" way. > > >> Probably that is not a significant issue for 99% of the users. > > >> > > >> I agree with Will's point that we should be thinking user-centrically in > > >> most of our discussion; however the point I made about remapping being > > >> more intrusive as a technique still applies. The use of CapsLock is, as > > >> Will pointed out in an earlier email, somewhat less clean and ideal > > >> technically than using some other modifier key. This is because, unlike > > >> the other keys, use of CapsLock is inherently "modal" (changes the X > > >> keyboard state in a "sticky" way) unless the CapsLock key is re-mapped > > >> to some other X keyboard symbol. > > >> > > >> Bill > > >> > > >> Janina Sajka wrote: > > >> > > >>> Bill Haneman writes: > > >>> > > >>> > > >>>> Thanks Will. That clarifies things somewhat - we're using the term > > >>>> "modifier key" differently. Maybe I'll contact you offlist for info > > >>>> on > > >>>> the internal details. > > >>>> > > >>>> So does that basically mean this whole discussion of orca on laptops > > >>>> is > > >>>> moot, or at least addressed fully via orca.settings.orcaModifierKeys > > >>>> (possibly with a UI for changing it easily) ? > > >>>> > > >>>> Bill > > >>>> > > >>>> > > >>>> > > >>> I shouldn't think so. This discussion has already pointed out that > > >>> CapsLock is the established default modifier for JFW users on Windows > > >>> and for Speakup users on Linux. Furthermore, it is reasonable to expect > > >>> that no new application is likely to adopt CapsLock for it's own uses, > > >>> i.e. we run the least risk of conflict both today and tomorrow by > > >>> defaulting to CapsLock as the default Orca laptop modifier. > > >>> > > >>> Of course, the fact that this is established practice and widely > > >>> expected by users both on Windows and Linux should really end this > > >>> discussion, from the user point of view. Choosing anything else will > > >>> certainly cause continuing confusion and displeasure among users, so > > >>> there'd need to be extremely powerful arguments to choose anything else. > > >>> I haven't heard arguments yet in this thread that strike me as > > >>> sufficiently convincing to look for some other modifier. > > >>> > > >>> It's available, achievable and remappable, and it's what users expect. > > >>> What else do we need to put this one to bed? > > >>> > > >>> Janina > > >>> > > >>> > > >>> > > >>> > > >>>> Willie Walker wrote: > > >>>> > > >>>> > > >>>>> Hi All: > > >>>>> > > >>>>> I don't think there's a need to map an existing X modifier to the Orca > > >>>>> modifier. Orca invents its own modifier internally and allows any key > > >>>>> to act as the Orca modifier. That's why Insert and KP_Insert can act > > >>>>> as > > >>>>> the Orca modifier key. As such, I'm not sure "which modifier" is an > > >>>>> important discussion to have. > > >>>>> > > >>>>> Will > > >>>>> > > >>>>> > > >>>>> > > >>>>> > > >>>>> > > >>>>> > > >>>> _______________________________________________ > > >>>> Orca-list mailing list > > >>>> [EMAIL PROTECTED] > > >>>> http://mail.gnome.org/mailman/listinfo/orca-list > > >>>> > > >>>> > > >>> > > >>> > > >> > > >> ------------------------------------------------------------------------ > > >> > > >> Index: orca/src/orca/orca.py > > >> =================================================================== > > >> RCS file: /cvs/gnome/orca/src/orca/orca.py,v > > >> retrieving revision 1.165 > > >> diff -p -u -r1.165 orca.py > > >> --- orca/src/orca/orca.py 7 Nov 2006 19:19:01 -0000 1.165 > > >> +++ orca/src/orca/orca.py 9 Nov 2006 14:44:10 -0000 > > >> @@ -857,6 +857,10 @@ def loadUserSettings(script=None, inputE > > >> debug.println(debug.LEVEL_CONFIGURATION, > > >> "Magnification module has NOT been initialized.") > > >> > > >> + for keyName in settings.orcaModifierKeys: > > >> + if keyName == "Caps_Lock": > > >> + os.system('xmodmap -e "clear Lock"') > > >> + > > >> _showMainWindowGUI() > > >> > > >> httpserver.init() > > >> > > > > _______________________________________________ > > Orca-list mailing list > > [EMAIL PROTECTED] > > http://mail.gnome.org/mailman/listinfo/orca-list > > _______________________________________________ > Orca-list mailing list > [EMAIL PROTECTED] > http://mail.gnome.org/mailman/listinfo/orca-list -- Janina Sajka Phone: +1.202.595.7777 Partner, Capital Accessibility LLC http://CapitalAccessibility.Com Marketing the Owasys 22C talking screenless cell phone in the U.S. and Canada--Go to http://ScreenlessPhone.Com to learn more. Chair, Accessibility Workgroup Free Standards Group (FSG) [EMAIL PROTECTED] http://a11y.org _______________________________________________ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
