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()
_______________________________________________
gnome-accessibility-list mailing list
gnome-accessibility-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
