Re: Orca on laptops.
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. Thanks everyone! The patch is in GNOME CVS HEAD and I opened an RFE to allow people to lock/unlock the Lock modifier when Orca is using the Caps_Lock key as its modifer: http://bugzilla.gnome.org/show_bug.cgi?id=373387 In the interest of not getting several copies of each e-mail regarding this subject, lets please move the discussion of how to enable lock/unlock to the RFE (you can add your comments to the RFE). If using bugzilla.gnome.org proves to be too cumbersome for some users, then lets please restrict the discussion of this to [EMAIL PROTECTED] BTW, I've tried to put the ubuntu-accessibility and gnome-accessibility-list addresses on the BCC line of this message as a means to get the message out, but prevent Reply All from going to a gazillion places. Hopefully the mail servers for those lists will accept this. Thanks! Will -- Ubuntu-accessibility mailing list Ubuntu-accessibility@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-accessibility
Re: Orca on laptops.
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 -- Ubuntu-accessibility mailing list Ubuntu-accessibility@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-accessibility
Re: Orca on laptops.
Hi Will. Just tried the patch. It works nicely. 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. To play devil's advocate: What about instances where folks are sharing the same computer but not using separate usernames, and not all of them are blind? Okay so it's a stretch ;-) Regardless, when you log out, xmodmap seems to get restored (read CapsLock works again). Take care. Joanie -- Ubuntu-accessibility mailing list Ubuntu-accessibility@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-accessibility
Re: Orca on laptops.
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 +, 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
Re: Orca on laptops.
To play devil's advocate: What about instances where folks are sharing
the same computer but not using separate usernames, and not all of them
are blind? Okay so it's a stretch ;-)
Good question, and not really a stretch when you think about public use
information systems. The Caps Lock behavior is only modified when you
run Orca, so users who don't use Orca should get the standard system
behavior. Plus the standard system behavior is restored when X is
restarted.
The only rub is this: assume an Orca user goes to the library, runs
Orca on the electronic card catalog system, quits Orca, and then leaves.
The default Caps Lock key behavior won't work for the next user until
the X server is restarted. I guess I could possibly imagine hearing
shouts come from the Hollis, NH, public library:
Damn computer! I'm looking for the enormously large collection of
books on 'GNOME', not 'gnome'. Why doesn't this Caps Lock key work? My
life is ruined. Down with Orca users! Kill them all! They must die!
Take their babies, too!.
We hear similar things from maladjusted pinball game players who want to
kill everyone associated with AccessX.
Here's a patch, however, that helps save the lives of innocent Orca
users. It rolls in the previous patch and adds a little save/restore
logic to the script that starts orca. It's not perfect, but it's
better.
Will
Index: orca/src/orca/orca.in
===
RCS file: /cvs/gnome/orca/src/orca/orca.in,v
retrieving revision 1.18
diff -p -u -r1.18 orca.in
--- orca/src/orca/orca.in 7 Sep 2006 19:44:52 - 1.18
+++ orca/src/orca/orca.in 9 Nov 2006 17:15:27 -
@@ -90,7 +90,16 @@ runOrca()
[EMAIL PROTECTED]@
[EMAIL PROTECTED]@
export PYTHONPATH
+
+# We'll save and restore the Caps_Lock as a modifier just in case
+# the user is using the Caps_Lock as the Orca modifier key.
+#
+CAPSLOCKSETTING=`xmodmap | grep Caps_Lock | cut -f1`
@PYTHON@ -c import orca.orca; orca.orca.main() $ARGS
+if [ x$CAPSLOCKSETTING != x ]
+then
+ xmodmap -e add $CAPSLOCKSETTING = Caps_Lock
+fi
}
# Runs a watchdog process in the background. It merely attempts to
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 - 1.165
+++ orca/src/orca/orca.py 9 Nov 2006 17:15:27 -
@@ -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()
--
Ubuntu-accessibility mailing list
Ubuntu-accessibility@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-accessibility
Re: Orca on laptops.
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? Eeks! I hope I can get this mail out to help prevent a storm. I mean Caps Lock would be the default for laptop use and Insert would be the default for normal desktop use. Will -- Ubuntu-accessibility mailing list Ubuntu-accessibility@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-accessibility
Re: Orca on laptops.
Willie Walker wrote: 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. I'd like to just say go forth and fix Firefox accessibility as that's what most interests /me/, but I feel I have to be responsible and point out that when a slightly jokey proposal to eliminate caps lock once and for all was laid before the Slashdot hordes it was rapidly revealed that certain corporate situations required data entry all in capitals: http://tinyurl.com/kvo3l See for example this comment on that submission: http://tinyurl.com/tg63q I'm not sure if that makes access to normal caps lock behaviour a must have or a nice to have. As far as I can see, it's not as crucial as effective web access, but that may be my bias talking. -- Benjamin Hawkes-Lewis -- Ubuntu-accessibility mailing list Ubuntu-accessibility@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-accessibility
Re: Orca on laptops.
Hi Will. If this constraint is acceptable, I think we're done. I think you're done. The functionality provided via the most recent patch (i.e. the one in which Caps Lock gets restored when you quit Orca) works very nicely. Thanks for doing it! Regarding an alternative way to have full Caps Lock functionality while using Orca: 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. It's a nice to have thing that should go into an RFE and marked as FUTURE. We need all of the things you've listed (especially compelling Firefox access) far more. For now, we can just hold down Shift as we type. :-) So...is the proposed solution acceptable? YES! Eeks! I hope I can get this mail out to help prevent a storm. I mean Caps Lock would be the default for laptop use and Insert would be the default for normal desktop use. That sounds great. Take care. Joanie -- Ubuntu-accessibility mailing list Ubuntu-accessibility@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-accessibility
RE: Orca on laptops.
I use the Capslock key as a modifyer instead of insert all the time with Jaws on laptops, and I like how it's implemented there. It appears to work with the capslock key latched or unlatched. -- Ubuntu-accessibility mailing list Ubuntu-accessibility@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-accessibility
Re: Orca on laptops.
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 -- Janina SajkaPhone: +1.202.595. 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) [EMAIL PROTECTED] http://a11y.org -- Ubuntu-accessibility mailing list Ubuntu-accessibility@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-accessibility
RE: Orca on laptops.
I vote for employing Insert and CapsLock as modifiers. This will emulate what's used in some Windows screen readers, and users will be accustomed to it, which is a good thing. Joe Lazzaro -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rich Burridge Sent: Wednesday, November 08, 2006 9:27 PM To: Janina Sajka Cc: Bill Haneman; Willie Walker; 'Ubuntu Accessibility Mailing List'; 'Gnome Accessibility List'; 'Orca screen reader developers' Subject: Re: Orca on laptops. Hi Janina, 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. One of the arguments for Insert (or rather KP_Insert, the 0 on the numeric keypad), is that you can do chords (Insert-whatever) with one hand, whilst the other hand could remain on the braille display. I can quantify how significant that is to a blind user. Hopefully other members of this list can speakup (sorry) and tell us. It's available, achievable and remappable, and it's what users expect. What else do we need to put this one to bed? My feeling is that we just need to pick a default that most people want. If that's CapsLock to be compatible with JAWS and Speakup, then so be it. As it's configurable, other users can adjust accordingly. ___ Orca-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/orca-list -- Ubuntu-accessibility mailing list Ubuntu-accessibility@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-accessibility
Re: Orca on laptops.
At the risk of beating on this to death ... Am I correct in the belief that we mean Insert and CapLocks interchangeably? If so, I agree. Insert is the long established default on full-sized keyboards. I don't believe this was at issue, in fact. CapLocks comes up only to facilitate laptop users where Insert is awkward, at best, and often plain impossible. Of course, once we have CapsLock, there's no reason to not use it as a modifier with a full-size keyboard, should a user wish. I suspect there is a point of divergence where a decision must be made, though. As I understand it, JFW uses Shift plus CapsLock to actually latch CapsLock. Speakup, on the other hand, uses Ctrl-CapsLock for this. I suggest the resolution we want is consistency, and I think we need to adopt practices already familiar in gnopernicus, orca, and indeed the Windows world. So, much as my Linux/Unix soul prefers Alt-Tab over Shift-Tab, I suspect the Shift-CapLocks should latch/unlatch caps. Janina Joe Lazzaro writes: I vote for employing Insert and CapsLock as modifiers. This will emulate what's used in some Windows screen readers, and users will be accustomed to it, which is a good thing. Joe Lazzaro -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rich Burridge Sent: Wednesday, November 08, 2006 9:27 PM To: Janina Sajka Cc: Bill Haneman; Willie Walker; 'Ubuntu Accessibility Mailing List'; 'Gnome Accessibility List'; 'Orca screen reader developers' Subject: Re: Orca on laptops. Hi Janina, 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. One of the arguments for Insert (or rather KP_Insert, the 0 on the numeric keypad), is that you can do chords (Insert-whatever) with one hand, whilst the other hand could remain on the braille display. I can quantify how significant that is to a blind user. Hopefully other members of this list can speakup (sorry) and tell us. It's available, achievable and remappable, and it's what users expect. What else do we need to put this one to bed? My feeling is that we just need to pick a default that most people want. If that's CapsLock to be compatible with JAWS and Speakup, then so be it. As it's configurable, other users can adjust accordingly. ___ Orca-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/orca-list -- Janina SajkaPhone: +1.202.595. 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) [EMAIL PROTECTED] http://a11y.org -- Ubuntu-accessibility mailing list Ubuntu-accessibility@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-accessibility
RE: Orca on laptops.
Hi Janina and All, I'm using Jaws 7.x, under Win XP Pro. When I want to lock or unlock the Capslock key, I just double strike the Capslock key very quickly. I'm not aware that you can use the Shift+Capslock combination to lock the Capslock. Joe Lazzaro -Original Message- From: Janina Sajka [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 08, 2006 10:17 PM To: lazzaro Cc: 'Rich Burridge'; 'Janina Sajka'; 'Bill Haneman'; 'Willie Walker'; 'Ubuntu Accessibility Mailing List'; 'Gnome Accessibility List'; 'Orca screen reader developers' Subject: Re: Orca on laptops. At the risk of beating on this to death ... Am I correct in the belief that we mean Insert and CapLocks interchangeably? If so, I agree. Insert is the long established default on full-sized keyboards. I don't believe this was at issue, in fact. CapLocks comes up only to facilitate laptop users where Insert is awkward, at best, and often plain impossible. Of course, once we have CapsLock, there's no reason to not use it as a modifier with a full-size keyboard, should a user wish. I suspect there is a point of divergence where a decision must be made, though. As I understand it, JFW uses Shift plus CapsLock to actually latch CapsLock. Speakup, on the other hand, uses Ctrl-CapsLock for this. I suggest the resolution we want is consistency, and I think we need to adopt practices already familiar in gnopernicus, orca, and indeed the Windows world. So, much as my Linux/Unix soul prefers Alt-Tab over Shift-Tab, I suspect the Shift-CapLocks should latch/unlatch caps. Janina Joe Lazzaro writes: I vote for employing Insert and CapsLock as modifiers. This will emulate what's used in some Windows screen readers, and users will be accustomed to it, which is a good thing. Joe Lazzaro -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rich Burridge Sent: Wednesday, November 08, 2006 9:27 PM To: Janina Sajka Cc: Bill Haneman; Willie Walker; 'Ubuntu Accessibility Mailing List'; 'Gnome Accessibility List'; 'Orca screen reader developers' Subject: Re: Orca on laptops. Hi Janina, 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. One of the arguments for Insert (or rather KP_Insert, the 0 on the numeric keypad), is that you can do chords (Insert-whatever) with one hand, whilst the other hand could remain on the braille display. I can quantify how significant that is to a blind user. Hopefully other members of this list can speakup (sorry) and tell us. It's available, achievable and remappable, and it's what users expect. What else do we need to put this one to bed? My feeling is that we just need to pick a default that most people want. If that's CapsLock to be compatible with JAWS and Speakup, then so be it. As it's configurable, other users can adjust accordingly. ___ Orca-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/orca-list -- Janina SajkaPhone: +1.202.595. 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) [EMAIL PROTECTED] http://a11y.org -- Ubuntu-accessibility mailing list Ubuntu-accessibility@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-accessibility
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 +, 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
Re: Orca on laptops.
Luke Yelavich wrote: ... In Windows, Jaws manages to prevent the capslock key from being latched or unlatched. To latch/unlatch, you press shift + Capslock, or press capslock twice quickly. I see. I expect that would be a hazardous and/or fragile thing to attempt on X, especially if, as I believe, the latching behavior is a hardware feature on some (most?) keyboards. On Windows you could circumvent this by meddling with the keyboard drivers, but I think we want to avoid getting that intrusive. So we should probably consider CapsLock to be an always-latching key, IMO. Bill -- Ubuntu-accessibility mailing list Ubuntu-accessibility@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-accessibility
Re: Orca on laptops.
On 11/8/06, Bill Haneman [EMAIL PROTECTED] wrote: Luke Yelavich wrote: ... In Windows, Jaws manages to prevent the capslock key from being latched or unlatched. To latch/unlatch, you press shift + Capslock, or press capslock twice quickly. I see. I expect that would be a hazardous and/or fragile thing to attempt on X, especially if, as I believe, the latching behavior is a hardware feature on some (most?) keyboards. On Windows you could circumvent this by meddling with the keyboard drivers, but I think we want to avoid getting that intrusive. So we should probably consider CapsLock to be an always-latching key, IMO. I thought the Gnome Keyboard preferences already allowed one to make CapsLock a simple modifier key for entering special characters? When this is done, is it still latching? -- Benjamin Hawkes-Lewis -- Ubuntu-accessibility mailing list Ubuntu-accessibility@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-accessibility
Re: Orca on laptops.
Bill Haneman: I see. I expect that would be a hazardous and/or fragile thing to attempt on X, especially if, as I believe, the latching behavior is a hardware feature on some (most?) keyboards. Hello, I'm using CapsLock as another Ctrl key. It is configurable through Gnome keyboard properties dialog (before it was there I used a modified xkb layout to achieve that). Without any deeper knowledge, I'd assume that this is not a hardware feature, when one is able to remap the key easily. Just a hint... Best regards, Tomas. -- Ubuntu-accessibility mailing list Ubuntu-accessibility@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-accessibility
Re: Orca on laptops.
Benjamin Hawkes-Lewis wrote: On 11/8/06, Bill Haneman [EMAIL PROTECTED] wrote: Luke Yelavich wrote: ... In Windows, Jaws manages to prevent the capslock key from being latched or unlatched. To latch/unlatch, you press shift + Capslock, or press capslock twice quickly. I see. I expect that would be a hazardous and/or fragile thing to attempt on X, especially if, as I believe, the latching behavior is a hardware feature on some (most?) keyboards. On Windows you could circumvent this by meddling with the keyboard drivers, but I think we want to avoid getting that intrusive. So we should probably consider CapsLock to be an always-latching key, IMO. I thought the Gnome Keyboard preferences already allowed one to make CapsLock a simple modifier key for entering special characters? When this is done, is it still latching? I don't see that option in the preferences dialog - you can indeed alter the way CapsLock works, and whether the Shift key cancels CapsLock or not, but it seems to be a latching key in all cases, as far as I can tell. regards Bill -- Benjamin Hawkes-Lewis ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list -- Ubuntu-accessibility mailing list Ubuntu-accessibility@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-accessibility
Re: Orca on laptops.
Tomas Cerha wrote: Bill Haneman: I see. I expect that would be a hazardous and/or fragile thing to attempt on X, especially if, as I believe, the latching behavior is a hardware feature on some (most?) keyboards. Hello, I'm using CapsLock as another Ctrl key. It is configurable through Gnome keyboard properties dialog (before it was there I used a modified xkb layout to achieve that). Without any deeper knowledge, I'd assume that this is not a hardware feature, when one is able to remap the key easily. Just a hint... Best regards, Tomas. Hi Tomas: Thanks for that bit of info. If you can configure CapsLock to emit Control instead, then I agree it's probably not latched in hardware. That said, modifying the xkb map is a somewhat intrusive technique - we may wish to do something that intrusive, but it does introduce complexities that could make testing and support more difficult. It would IMO be nicer if we could work with most XKB default key maps rather than having to modify them in order to achieve our desired behavior. XKB does give some pretty powerful APIs for modifying key behaviors, via the XkbKeyAction model I think. regards Bill regards Bill ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list -- Ubuntu-accessibility mailing list Ubuntu-accessibility@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-accessibility
Re: Orca on laptops.
Bill Haneman wrote: I don't see that option in the preferences dialog - you can indeed alter the way CapsLock works, and whether the Shift key cancels CapsLock or not, but it seems to be a latching key in all cases, as far as I can tell. You can make it a Ctrl in Ctrl key position - Make CapsLoct an additional Crtl. And it is a regular - non-latching Ctrl key. Take care, Tomas. -- Ubuntu-accessibility mailing list Ubuntu-accessibility@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-accessibility
Re: Orca on laptops.
On 11/8/06, Bill Haneman [EMAIL PROTECTED] wrote: I don't see that option in the preferences dialog - you can indeed alter the way CapsLock works, and whether the Shift key cancels CapsLock or not, but it seems to be a latching key in all cases, as far as I can tell. Just tested it on my Ubuntu Edgy box, and as far I can tell you're mistaken. In Keyboard preferences, look for the Layout Options, then Compose key position. Now I have a British Thinkpad keyboard. If I tick Right alt is compose then pressing [AltGr] + ['] (that's apostrophe) then [e] outputs an e acute. But let's say I tick Caps Lock is Compose. Now two things happen. First Caps Lock no longer affects capitalization. And second, it acts just like [AltGr] before. If I press [Caps Lock] + ['] then [e], it outputs an e acute. But pressing [Caps Lock] then ['] then [e] outputs an apostrophe then a normal e. Doesn't that imply it is no longer latching? -- Benjamin Hawkes-Lewis -- Ubuntu-accessibility mailing list Ubuntu-accessibility@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-accessibility
Re: Orca on laptops.
Tomas Cerha writes (Re: Orca on laptops.):
Hello, I'm using CapsLock as another Ctrl key. It is configurable
through Gnome keyboard properties dialog (before it was there I used a
modified xkb layout to achieve that). Without any deeper knowledge, I'd
assume that this is not a hardware feature, when one is able to remap
the key easily. Just a hint... Best regards, Tomas.
Indeed, The caps lock key can easily be remapped. I for example use it
as another Control key, because it is more easily reachable than the
one in the bottom left corner of the keyboard. There are plenty of
HowTos on the web that explain how to remap this key both under X and
the Linux console. The locking behaviour is therefore certainly not a
property of the hardware. CapsLock is just like any other key.
The AltGr key is not suitable as a general modifier key for orca on
many international keyboard layouts. It is needed on some layouts to
type characters as common as @ \ | [ ] { } ~ and '.
I would therefore say that CapsLock is the more suitable choice of the
two as a default orca modifier key on laptops.
Best regards, Lukas
--
Ubuntu-accessibility mailing list
Ubuntu-accessibility@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-accessibility
Re: Orca on laptops.
Bill Haneman, le Wed 08 Nov 2006 13:24:53 +, a écrit : Luke Yelavich wrote: ... In Windows, Jaws manages to prevent the capslock key from being latched or unlatched. To latch/unlatch, you press shift + Capslock, or press capslock twice quickly. I see. I expect that would be a hazardous and/or fragile thing to attempt on X, especially if, as I believe, the latching behavior is a hardware feature on some (most?) keyboards. It was on some old keyboard, but with PC keyboard it is just a regular key. Samuel -- Ubuntu-accessibility mailing list Ubuntu-accessibility@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-accessibility
Re: Orca on laptops.
On my french keyboard, Mod2 is Numlock, Mod4 is Windows and Mod5 is AltGr. I didn't manage to hit Mod3. Samuel -- Ubuntu-accessibility mailing list Ubuntu-accessibility@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-accessibility
Re: Orca on laptops.
Bill Haneman wrote: Lukas Loehrer wrote:... I would therefore say that CapsLock is the more suitable choice of the two as a default orca modifier key on laptops. I don't wish to belabor this point, but I find that terminology confusing. If we remap the CapsLock key, then we are not using the CapsLock modifier at all! The question remains, then, what modifier do we assign to the (physical) CapsLock key? in order to use it for orca. Orca doesn't care what kind of key it uses for its modifier key. It can be anything. If anybody wants to try using CapsLock to see if they are more comfortable with it, then you can adjust the orca.settings.orcaModifierKeys line in ~/.orca/user-settings.py to: orca.settings.orcaModifierKeys = ['Caps_Lock'] -- Ubuntu-accessibility mailing list Ubuntu-accessibility@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-accessibility
Re: Orca on laptops.
Rich Burridge wrote: Orca doesn't care what kind of key it uses for its modifier key. It can be anything. Yes, but I think there is some agreement that finding a reasonable default modifier is a worthwhile goal. Bill If anybody wants to try using CapsLock to see if they are more comfortable with it, then you can adjust the orca.settings.orcaModifierKeys line in ~/.orca/user-settings.py to: orca.settings.orcaModifierKeys = ['Caps_Lock'] -- Ubuntu-accessibility mailing list Ubuntu-accessibility@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-accessibility
Re: Orca on laptops.
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 I think we need to resolve this second issue (i.e. of what _modifier_ we use for orca) before dealing with the first issue (i.e. what physical key we wish to assign that modifier to). As I said originally, we only have a few modifiers to choose from, whatever physical keys we wish to map them to. From X.h, we have: Shift Lock Control Mod1 (usually Alt) Mod2 (usually 'Meta' ?) Mod3 (usually NumLock?) Mod4 (Windows or Menu key, depends on the xkb map) Mod5 (not sure about this one, either Windows or Menu key on some maps) I suppose we could use 'Meta', provided we don't mind remapping some physical key in existing keymaps, since it doesn't seem to be widely used on PC laptops these days. The API call which should be used to determine how a particular keysym maps to a particular modifier bit (for Mod1 through Mod5) looks like this: meta_mask = XkbKeysymToModifiers (display, XK_Meta_L); Note that in theory left and right versions of the 'Meta','Control', etc. keysyms could be mapped to different mask bits. best regards, Bill Best regards, Lukas ___ ___ Orca-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/orca-list -- Ubuntu-accessibility mailing list Ubuntu-accessibility@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-accessibility
Re: Orca on laptops.
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 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 -- Ubuntu-accessibility mailing list Ubuntu-accessibility@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-accessibility
Re: Orca on laptops.
Cleverson wrote: Hi all My suggestion is that we don't have a single laptop layout, but perhaps three to five layouts matching several kinds of keyboards. I think we should try to avoid this if we can. A single keyboard layout for laptops will be easier to maintain and support (such as on-line documentation). Perhaps we can have have one default laptop layout that works well on most machines and then have small 'patch' alterations for exceptions. So one layout might work well on 90% of laptops, but you then have a standard alteration for Macs, old Toshibas, etc. There could be quite a few of those, but the changes in each would be simple. Henrik -- Ubuntu-accessibility mailing list Ubuntu-accessibility@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-accessibility
Re: Orca on laptops.
Hello all, Speakup had a the capslock key as a modifier for laptops, with the right-hand part of the keyboard being used in place of the numpad keys, e.g. uio = 789 jkl = 456 m,. = 123 I can't remember what they did for /, *, -, +, ., or the enter key, but I'm sure of the main part. I didn't use it much as I didn't have a laptop at the time, but I experimented with it and thought it was pretty sensible. Terrence Terrence m,./ or something like that. -- Ubuntu-accessibility mailing list Ubuntu-accessibility@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-accessibility
Re: Orca on laptops.
Perhaps I should be clearer about my experiences with capslock as a modifier. I'm assuming now that shiftlock and capslock are the same thing. In Speakup, capslock serves as the modifier key to get access to the screen reading keys, and does not in fact toggle on and off. To enable the USUAL behavior, I would hit the shift key plus the shiftlock key, then do the same to disable it. Terrence -- Ubuntu-accessibility mailing list Ubuntu-accessibility@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-accessibility
Re: Orca on laptops.
With regards to alternatives to the numeric keypad, might it make sense to offer Emacs- and Vim-style movement keys as options? Just a thought. Also, as though to prove how important this issue is, here's a post just sent to the Mozilla dev-accessibility list in which a would-be Ubuntu and Orca user despairs over his inability to manage keyboard combinations and shortcuts: http://tinyurl.com/yde2sm Does anyone happen to know how he could restore default Gnome settings for keyboard shortcuts? I had a look in my home directory and GConf and couldn't work out where the main shortcuts are stored. -- Ubuntu-accessibility mailing list Ubuntu-accessibility@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-accessibility
Re: Orca on laptops.
Hi Janina, 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. One of the arguments for Insert (or rather KP_Insert, the 0 on the numeric keypad), is that you can do chords (Insert-whatever) with one hand, whilst the other hand could remain on the braille display. I can quantify how significant that is to a blind user. Hopefully other members of this list can speakup (sorry) and tell us. It's available, achievable and remappable, and it's what users expect. What else do we need to put this one to bed? My feeling is that we just need to pick a default that most people want. If that's CapsLock to be compatible with JAWS and Speakup, then so be it. As it's configurable, other users can adjust accordingly. -- Ubuntu-accessibility mailing list Ubuntu-accessibility@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-accessibility
Re: Orca on laptops.
Rich Burridge wrote: I can quantify how significant that is to a blind user. That should have course been: I can't quantify how significant that is to a blind user. -- Ubuntu-accessibility mailing list Ubuntu-accessibility@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-accessibility
Re: Orca on laptops.
Luke Yelavich, le Wed 08 Nov 2006 06:21:58 +1100, a écrit : So what modifier key would you like to use for Orca? Couldn't this be just configurable? Samuel -- Ubuntu-accessibility mailing list Ubuntu-accessibility@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-accessibility
Re: Orca on laptops.
So what modifier key would you like to use for Orca? Couldn't this be just configurable? I agree that this would make the most sense. As Luke pointed out, there are so many different layouts (not to mention so many different users). Is there a reason we need to select THE Orca modifier key? --Joanie -- Ubuntu-accessibility mailing list Ubuntu-accessibility@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-accessibility
Re: Orca on laptops.
Joanmarie Diggs wrote: So what modifier key would you like to use for Orca? Couldn't this be just configurable? I agree that this would make the most sense. As Luke pointed out, there are so many different layouts (not to mention so many different users). Is there a reason we need to select THE Orca modifier key? I agree that configurability makes sense. However, I think choosing a reasonable laptop default is also important, because there are so many potential conflicts; it's quite likely that only one or two choices are really usable for people. For instance, you don't want to lose the use of menu shortcuts, access keys, or keyboard navigation while using orca - all of which could come in to conflict with one's chosen modifier key. There are really only 8 possible modifiers in XWindows I think - corresponding to the first 8 bits in the modifier mask. That includes ShiftLock and Shift. I guess one possible way to get out of the conflict situation would be to exclude ShiftLock from the orca modifier mask; that is, ignore any orca commands that are executed with ShiftLock on. This would give a quick and relatively easy way to access any key combinations/shortcuts that were in conflict with orca commands. For instance, if orca used 'Control', one could still access cut and paste via Control-X and Control-V by pressing ShiftLock first. On my system, the Windows key seems to map to one of the Xserver modifier masks, whereas the Menu key seems to be some sort of function key. I am sure that this varies from laptop to laptop quite widely. If you choose to rule out the Windows meta key, then on many laptops you only will have Control, Alt, and AltGr, practically speaking. Alt seems like a troublesome choice since the majority of keyboard shortcuts in Gnome use Alt. AltGr is one that often gets forgotten; what about that? It does appear to be a modifier key on all the systems I am aware of. regards Bill --Joanie ___ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list -- Ubuntu-accessibility mailing list Ubuntu-accessibility@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-accessibility
Re: Orca on laptops.
Bill Haneman, le Tue 07 Nov 2006 20:15:53 +, a écrit :
AltGr is one that often gets forgotten; what about that? It does appear
to be a modifier key on all the systems I am aware of.
Yes, but it's widely used for typing ~, #, {, [, |, `, \, ^, @, ], },
€, «, », œ, æ, ß, ...
Samuel
--
Ubuntu-accessibility mailing list
Ubuntu-accessibility@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-accessibility
Re: Orca on laptops.
Joanmarie Diggs wrote: So what modifier key would you like to use for Orca? Couldn't this be just configurable? I agree that this would make the most sense. As Luke pointed out, there are so many different layouts (not to mention so many different users). Is there a reason we need to select THE Orca modifier key? It's already configurable. Look for the following line in your ~/.orca/user-settings.py file: orca.settings.orcaModifierKeys = ['Insert', 'KP_Insert'] For bonus points, we do need to whack a GUI on this and make it easier to configure, but it's definitely doable. -- Ubuntu-accessibility mailing list Ubuntu-accessibility@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-accessibility
Re: Orca on laptops.
Bill Haneman, le Tue 07 Nov 2006 20:35:47 +, a écrit :
Yes, but it's widely used for typing ~, #, {, [, |, `, \, ^, @, ], },
€, «, », œ, æ, ß, ...
Agreed, but doesn't orca use arrow keys for many of its functions?
I use altgr-arrows for producing ←→↑↓ :)
I know there are lots of keys which AltGr doesn't appear to do
anything with.
On an american qwerty keyboard maybe, but even latin languages need a
bunch of algr keys.
Samuel
--
Ubuntu-accessibility mailing list
Ubuntu-accessibility@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-accessibility
Re: Orca on laptops.
Luke Yelavich, le Wed 08 Nov 2006 07:43:42 +1100, a écrit : On Wed, Nov 08, 2006 at 07:35:47AM EST, Bill Haneman wrote: Agreed, but doesn't orca use arrow keys for many of its functions? I know there are lots of keys which AltGr doesn't appear to do anything with. I have never heard of AltGr. What key is this? It is also known as right alt: that's the key just on the right side of the space bar. It is used for expending what can be typed on a keyboard. Mandatory for many (all?) non-english languages. Samuel -- Ubuntu-accessibility mailing list Ubuntu-accessibility@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-accessibility
Re: Orca on laptops.
Hi Bill. I guess one possible way to get out of the conflict situation would be to exclude ShiftLock from the orca modifier mask; But Might not ShiftLock be an ideal modifier key for some? I also think it would be preferable to have it as a modifier rather than as the key that makes all of the keyboard shortcuts I normally use on my desktop work on my laptop. :-) AltGr is one that often gets forgotten; what about that? It does appear to be a modifier key on all the systems I am aware of. This idea I like. On my laptops, AltGr doesn't seem to be doing anything useful (like allowing me to get into menus). And every laptop I've seen has had this key. Take care. Joanie -- Ubuntu-accessibility mailing list Ubuntu-accessibility@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-accessibility
Re: Orca on laptops.
There's nothing wrong with having sensible defaults, but I struggle to believe there is a set of magic bindings which work on all hardware. How about running a configuration program at Orca's first startup that would take information about the user's keyboard as input (the Ubuntu installer already includes a program for guessing keyboard layouts) and generate a set of sane defaults based on that? We would need two basic Orca sets: one for keyboards with easy number pad access, and one for keyboard layouts without. The remaining problem is what would be the Orca modifier key. How about a list of potential Orca keys in order of preference, with the configuration program presenting the first available key as default. How about something like the following list: Right Windows key Left Windows key Insert AltGr/Right alt Scroll lock Caps Lock Access IBM and similar keys Special navigation keys (my Thinkpad has back and forwards keys for web navigation) It seems to me crucial to change Orca (and LSR) keys from the same control panel that configures other Gnome key bindings in order to minimize conflicts with core Gnome bindings for application functionality and special character entry. The question of the Orca keys is but a symptom of a much larger problem. Key bindings, with their inherent tension between supplementing and replacing the mouse, between interfaces accessible and making them faster, are a naturally complex subject. In the case of Linux, the horrible problem of key bindings is exacerbated both by the sheer range of hardware that can run Linux and by the glorious chaos of its software. Running Vim in a Gnome Terminal or a web application in Mozilla on Gnome with Orca enabled creates a serious potential for conflicts between key bindings. And when you're dependent on the keyboard, such conflicts threaten basic usability. Despite its intrinsic difficulties, the problem of key bindings is extremely unsexy. So if I were to say, for example, that we need a control panel that, when the user changes a key binding, can introspect the configuration files of key end-user applications for conflicts, I am not optimistic I would attract many enthusiasts for building it. Yet that is precisely what a humane interface for configuring key bindings demands. If one baulks even at the idea of coding a program that can juggle key bindings, is it fair to expect human beings to do so? Surely a control panel that could resolve conflicts between web access keys and Orca, or Vim and Orca is not intrinsically impossible? The biggest obstacle would seem to be gathering information about the modes and contexts in which console application key combinations apply, but that's not exactly an insurmountable problem. -- Benjamin Hawkes-Lewis -- Ubuntu-accessibility mailing list Ubuntu-accessibility@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-accessibility
Re: Orca on laptops.
Couldn't this be just configurable? Yes but we'd really like to offer a default to help users get started more quickly. Mike -- Ubuntu-accessibility mailing list Ubuntu-accessibility@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-accessibility
Re: Orca on laptops.
Hi Bill. I am not sure I understand your point - or perhaps you are misunderstanding me. I suspect it's the former, but we'll see. :-) What I am suggesting is that we specifically _avoid_ using ShiftLock And what I am suggesting is that we specifically _allow_ using it (if possible). (which is generally a troublesome 'modifier' anyhow, because it always has latch behavior, i.e. toggles between on/off with successive keypresses). I did wonder about this. I do know that in some Windows AT products, ShiftLock is used as a modifier key. How they went about accomplishing this, however, I couldn't tell you. Sorry if this sounds complicated, I am not sure how to put it more straightforwardly. I think you're putting it quite straightforwardly, and I apologize for not doing the same. If you'll permit me to try again: What I would like to avoid, if possible, is the need for loopholes and work arounds. I *very rarely* use ShiftLock when I type, and I *very frequently* rely upon shortcuts, access keys, etc. Therefore *for me*, having ShiftLock as a possible modifier makes sense. Having it become the additional key that I need to press in order to be able to use existing shortcuts, access keys, etc. sounds like an excellent reason to purchase an external keypad. :-) Thanks much for your explanation! Take care. --Joanie -- Ubuntu-accessibility mailing list Ubuntu-accessibility@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-accessibility
Re: Orca on laptops.
Hi All: Just an FYI that there is a related RFE to allow customization of key and braille bindings for Orca: http://bugzilla.gnome.org/show_bug.cgi?id=354970 Will -- Ubuntu-accessibility mailing list Ubuntu-accessibility@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-accessibility
Re: Orca on laptops.
Hi all My suggestion is that we don't have a single laptop layout, but perhaps three to five layouts matching several kinds of keyboards. Thus, when an user first-boot the CD, the first question might be: Select your kind of keyboard, and the correct layout would be applied. Thanks, Cleverson -- Ubuntu-accessibility mailing list Ubuntu-accessibility@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-accessibility
