Orca on laptops.

[Willie Walker]

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.

On a higher level, I'd like for all of us to step back and look at the
larger picture.  We might be attempting to boil the ocean when all we
want is a cup of tea.  

The proposed solution offers the ability to get Caps Lock working as the
Orca modifier, and it requires very little effort from the end user (or
none at all if we make Caps Lock the default modifier).  It does,
however, have the following constraint:  if you are an Orca user who has
specified "Caps_Lock" as your Orca modifier key, you lose normal Caps
Lock behavior when you run Orca.  Keep in mind this is a "transient"
behavior in that Orca does not modify any persistent system or user
settings related to X.  The behavior is only changed for that single run
of the X Server.  If you restart the X Server, default system behavior
comes back until you run Orca again.

If this constraint is acceptable, I think we're done.  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.  

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.

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

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 at 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 at gnome.org
> http://mail.gnome.org/mailman/listinfo/orca-list