GNOME.org
 

Re: Orca on laptops.

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
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]