Re: Orca on laptops.

[Janina Sajka <janina rednote net>]

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
> > >>>> Orca-list gnome org
> > >>>> 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
> > Orca-list gnome org
> > http://mail.gnome.org/mailman/listinfo/orca-list
> 
> _______________________________________________
> Orca-list mailing list
> Orca-list gnome org
> 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)
janina freestandards org		http://a11y.org