Orca on laptops.

[Willie Walker]

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
> >>     
> >
> >   
> 
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: capslock.patch
Type: text/x-patch
Size: 678 bytes
Desc: not available
Url : https://lists.ubuntu.com/archives/ubuntu-accessibility/attachments/20061109/1b71dcb4/attachment.bin