Re: Orca on laptops.
Hi all, Actually, when I used speakup, the latching key for capslock was shift. If I wanted the NORMAL capslock behaviorr, I would hit shift-capslock. Terrence -- Ubuntu-accessibility mailing list Ubuntu-accessibility@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-accessibility
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.
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 locki
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-) 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.
Yes, it's significantly intrusive from the perspective of the user who doesn't rely on Orca. So, it should come and go with the loading and unloading of Orca. On the other hand, as I tried to suggest, the reason it has proven so reliable for screen readers is precisely the fact that other applications are highly unlikely ever to map it for their own peculiar uses. We can't say that of any other key, and frankly of most any other key combination. Janina Bill Haneman writes: > 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 > >> > > > > -- 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.
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-) 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.
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-) 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.
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 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.
Go to the directory containing the 'orca' directory (i.e., the directory you were in when you did a cvs co orca). Then... patch -p0 < capslock.patch Or...wait until tomorrow and it will be in CVS unless someone has a compelling reason to not do this. Will On Thu, 2006-11-09 at 09:33 -0900, Terrence van Ettinger wrote: > So I assume this would be done with the patch command? What file > should I patch with it? Would it just be "patch orca I need to use the -p option with it? I'll confess I'm not much of a > programmer type, and want to get this right. > > Thanks, > Terrence > > -- Ubuntu-accessibility mailing list Ubuntu-accessibility@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-accessibility
Re: Orca on laptops.
So I assume this would be done with the patch command? What file should I patch with it? Would it just be "patch orca https://lists.ubuntu.com/mailman/listinfo/ubuntu-accessibility
Re: Orca on laptops.
Noted. For those users that absolutely positively need to set the lock modifier, they can set the Orca modifier to something else. This isn't perfect, but it is workable. If there are no reasonable objections by the end of the day, I'm going to consider discussion of this issue closed and the proposal accepted. I'll check in the patch tomorrow morning and will log a FUTURE RFE for allowing the Lock modifier to be locked when Caps Lock is under Orca's spell. Thanks everyone! This has been a rather long, but useful and important, discussion. I think we've come to a reasonable conclusion. Will PS - Instead of Caps Lock, I say get rid of "w". It upsets the pattern I used to memorize Grade 1 Braille. Heck, it's really a double U (or double V if you're French), and I'm happy to spell my name UUillie or VVillie. On Thu, 2006-11-09 at 17:41 +, Benjamin Hawkes-Lewis wrote: > 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 > > ___ > 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. > 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.
Hi Will. > "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!". And folks say libraries -- and Hollis -- are boring ;-) > 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. Do we need "perfection"? This patch seems to accomplish exactly what we need, namely enabling us to use Caps Lock as a modifier and restoring that key's functionality upon quitting Orca. Very, very cool! Take care. Joanie -- 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.
> 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.
> 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.
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 com
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.
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 +, 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 mo
Re: Orca on laptops.
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 +, 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 all
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.
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.
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-) 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.
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.
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.
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.
InSpeakup, capslock was the modifier for screen reading, and the usual capslock behavior was gotten by hitting shift-capslock. Perhaps that would work for Orca? Terrence -- 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.
> 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) ? I don't think the "whole discussion" is moot. The discussion up to this point has been around the modifier key (which I, for one, do think is addressed). Now the question is what keys to use *with* that modifier for performing flat review, whereAmI, etc. since we are lacking a keypad. -- Ubuntu-accessibility mailing list Ubuntu-accessibility@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-accessibility
Re: Orca on laptops.
On Wed, 2006-11-08 at 16:43 +, Bill Haneman wrote: > 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. I think the main goals are not technical, but are more about what users want and expect. These include things such as the following: 1) Users don't want to have to keep moving their hands away from the home row (ASDFGHJKL) and away from the braille display. 2) User's do not want contortionist chording, and chording with one hand is preferred (though on the laptop this may be difficult) In Orca, we can take care of turning almost any key into the Orca modifier key. Keys where we cannot control their locking behavior (e.g., Caps_Lock) are the current exceptions. These exceptions, however, are more along the lines of the fact that users don't expect the key to latch. That is, they expect to use chording with the modifier key versus having it lock. The Orda modifier key does not have to be a standard modifier key, and I think we should gear our discussion towards the user centered point of view versus the technology point of view, and then adjust if the technology cannot meet the desires. For example, the Caps_Lock key is causing us to adjust. Will -- 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.
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.
Hi Bill. > 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). At the risk of asking a silly question Why can't we just do what Rich suggested yesterday, namely change orca.settings.orcaModifierKeys to suit our personal needs? I took this line: orca.settings.orcaModifierKeys = ['Insert', 'KP_Insert'] Turned it into this line: orca.settings.orcaModifierKeys = ['Insert', 'Caps_Lock'] Now my CapsLock/ShiftLock works very nicely as the Orca modifier -- just like Insert. Take care. Joanie -- 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.
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.
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.
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. If we remap CapsLock to 'control', then the regular control key will of necessity have the same effect. This would also continue to conflict with the "normal" uses of the control key. 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 > ___ -- 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.
Hi Benjamin: I see, you're talking about a different thing from what I was referring to - I thought you were talking about the "CapsLock behavior" settings, which are all latching. What you have done, as far as I can tell, is re-map the CapsLock key to be a different key altogether - so it's no longer CapsLock from the Xserver or keymap point of view. Using XKB and similar APIs we can alter an existing keymap, remapping pretty much any key to pretty much any other keysym; similarly, there are pieces of the XKB API that would allow us to implement almost any behavior we want; however, this would be at the cost of complexity both in orca and in testing/verification. I think we should be careful to distinguish between using/adapting the behaviors of the existing key symbols in existing keymaps, and altering those keymaps fundamentally. In your example of re-mapping CapsLock to "Compose", I would suggest that CapsLock no longer exists in the keymap and so it is potentially confusing to refer to this key as "CapsLock" in our discussions. It does, however, point out the potential for using remapping to "create" any key via remapping, even for physical keyboards that don't include that key in their default printed key set. For instance, the keymap alteration technique above could be used to provide AltGr on Calum's iBook even though the default keyboard map doesn't include it, and there is no key labelled "AltGr" on the physical keyboard. So for instance if we decide that "right shift" should do something special in orca, we could use remapping to assign "XK_shift_right" to any physical key we chose. This means of course that the original use of the key in question would no longer be available, just as in Benjamin's example the CapsLock key no longer affects the 'ShiftLock' modifier; in effect CapsLock ceases to be available in such a scenario. Best regards, Bill > Benjamin Hawkes-Lewis wrote: > 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 > ___ > 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 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.
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.
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.
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.
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.
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.
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.
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 Wed, Nov 08, 2006 at 10:38:22PM EST, Bill Haneman wrote: > lazzaro wrote: > >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. > > > CapsLock always latches, in every keyboard I've encountered (i.e. that's > why it's called "Lock") - not sure what you mean here by an 'unlatched' > CapsLock key? 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. -- Luke Yelavich GPG key: 0xD06320CE (http://www.themuso.com/themuso-gpg-key.txt) Email & MSN: [EMAIL PROTECTED] Jabber: [EMAIL PROTECTED] signature.asc Description: Digital signature -- Ubuntu-accessibility mailing list Ubuntu-accessibility@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-accessibility
Re: Orca on laptops.
lazzaro wrote: > 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. > CapsLock always latches, in every keyboard I've encountered (i.e. that's why it's called "Lock") - not sure what you mean here by an 'unlatched' CapsLock key? 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.
On 7 Nov 2006, at 21:12, Joanmarie Diggs wrote: > > 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. Macintosh laptops don't have it (at least, my Powerbook doesn't). Cheeri, Calum. -- CALUM BENSON, Usability Engineer Sun Microsystems Ireland mailto:[EMAIL PROTECTED]Java Desktop System Team http://blogs.sun.com/calum +353 1 819 9771 Any opinions are personal and not necessarily those of Sun Microsystems -- 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
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.
Joanmarie Diggs wrote: > 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. :-) > Hi Joanie: I understand your point now, and you made it clearly, thanks. I think it comes down to how one uses the orca modifier or shortcuts. If one's orca use is highly "modal", i.e. one tends to stay in "orca mode" or "pure keyboard mode", then the latching behavior of ShiftLock could be an advantage, and I agree that it would make a useful modifier in that scenario. On the other hand, if the user model is less modal, and the user is frequently interspersing single orca commands within a stream of "normal" application keynav, the ShiftLock latching behavior would be a big annoyance. I think that flat-review tends to be "modal", i.e. you're either in review mode or you aren't, where as many of the other orca commands may be less so. I'll leave it to the orca designers and users to figure out where the balance lies. If you do find that some features are rather modal, there are two other latching keys available on many, but not all, keyboards, including laptop keyboard - NumLock and ScrollLock, so they may end up figuring into the discussion as well; in my experience NumLock can be either Mod3 or Mod4 in the Xserver modifier mask, depending on the X server implementation. (I am not sure ScrollLock actually appears in the modifier mask at all) regards, Bill > 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 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.
Joanmarie Diggs wrote: > 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 am not sure I understand your point - or perhaps you are misunderstanding me. What I am suggesting is that we specifically _avoid_ using ShiftLock (which is generally a troublesome 'modifier' anyhow, because it always has "latch" behavior, i.e. toggles between on/off with successive keypresses). ShiftLock is normally one of the modifier keys which are included in the "modifier state" of the keyboard; that is, it affects the behavior of the other keys. We can leverage this behavior by leaving it in the set of modifiers which affect orca, but by not using it as the "orca command modifier". This would allow orca users to access orca keys quickly, without latching behavior (i.e. just "Alt-Home" for instance), but still give orca a way of accessing any other keyboard shortcuts associated with the orca command modifier. The reason this would work is, because ShiftLock is treated somewhat differently by applications and the X server, most shortcuts ignore the ShiftLock state, and work the same whether ShiftLock is on or off. For those few situations where the ShiftLock state actually does matter, the user can press "Shift" to reverse the sense of ShiftLock and thus accomplish the same keystroke, without invoking the orca command. Sorry if this sounds complicated, I am not sure how to put it more straightforwardly. To use examples again, I think that the ShiftLock "loophole" could give us a way to work around the potential conflicts with any other modifier, for instance Alt, or Control, or even AltGr - for instance if we decided to make AltGr the orca modifier, Samuel could still insert his graphical arrow symbols with (CapsLock)+shift+AltGr+arrow Or if the orca command modifier were "Alt", and orca used the TAB key as a command key (a bad choice IMO), you could still switch windows with (CapsLock)+Alt+TAB; or if the orca command modifier were "Control", you could move focus within a treeview with (CapsLock)+Control+arrow. Basically I think that the combinations of Alt, Control, or Shift with arrow keys are already used elsewhere in the desktop somewhere, so conflict seems inevitable. At least this technique would give us a workaround - we would still of course want to try to reduce the conflicting set of keys to the smallest one we could. Bill > 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 > > ___ > 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.
> 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.
Samuel Thibault wrote: > > 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. > > Even on Apple Mac hardware ? The keyboard is really far from PC > keyboards... Perhaps I wasn't clear. I'm saying that there is no set of key bindings which will work on all hardware. Therefore we need more than one set of default layouts. Samuel Thibault asks: > Wouldn't it be possible, when orca is very first launched, to just ask > the user to press the key she will want to use, and then let her > configure it again later on if needed? It's not quite that simple, because some users have easy access to numeric keypads and some don't, as the original post mentioned. But whatever defaults are suggested, the user should be allowed to override on start up. Users do need guidance, however, as some will be using not just Orca but Linux for the first time. -- Benjamin Hawkes-Lewis -- Ubuntu-accessibility mailing list Ubuntu-accessibility@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-accessibility
Re: Orca on laptops.
Benjamin Hawkes-Lewis, le Tue 07 Nov 2006 21:22:39 +, a écrit : > 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. Even on Apple Mac hardware ? The keyboard is really far from PC keyboards... Wouldn't it be possible, when orca is very first launched, to just ask the user to press the key she will want to use, and then let her configure it again later on if needed? Samuel -- 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.
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.
Luke Yelavich wrote: > ... > Well I don't think that will be an option, as some laptops don't have a > right Alt, as far as I am aware, or I could be getting that mixed up > with the right control key. > I think you might have that confused, yes. Any non-English laptop would need AltGr for the reasons Samuel mentioned. I think it might be worth looking at a few examples key layouts for AltGr in different european languages, to see how significant the potential conflict Samuel mentions actually is. We do have the reality, currently, that orca only really works in languages for which we have text-to-speech voices and/or braille tables (and I think we have more of the latter than the former, at the moment). (I think GOK can be used as a quick check for this, BTW; if you change your keyboard layout, bring up the 'Compose' keyboard, and press AltGr, GOK should display the relevant characters.) Bill -- 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:51:39 +1100, a écrit : > On Wed, Nov 08, 2006 at 07:48:57AM EST, Samuel Thibault wrote: > > 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. > > Well I don't think that will be an option, as some laptops don't have a > right Alt, as far as I am aware, or I could be getting that mixed up > with the right control key. The right control key is another key indeed. Some french laptop don't have a right control key (but of course have a right alt, since it's mandatory for french), so I guess some american laptops may lack the right alt key. Samuel -- Ubuntu-accessibility mailing list Ubuntu-accessibility@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-accessibility
Re: Orca on laptops.
On Wed, Nov 08, 2006 at 07:48:57AM EST, Samuel Thibault wrote: > 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. Well I don't think that will be an option, as some laptops don't have a right Alt, as far as I am aware, or I could be getting that mixed up with the right control key. -- Luke Yelavich GPG key: 0xD06320CE (http://www.themuso.com/themuso-gpg-key.txt) Email & MSN: [EMAIL PROTECTED] Jabber: [EMAIL PROTECTED] signature.asc Description: Digital signature -- 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.
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? -- Luke Yelavich GPG key: 0xD06320CE (http://www.themuso.com/themuso-gpg-key.txt) Email & MSN: [EMAIL PROTECTED] Jabber: [EMAIL PROTECTED] signature.asc Description: Digital signature -- 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.
Samuel Thibault wrote:
> 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 ~, #, {, [, |, `, \, ^, @, ], },
> €, «, », œ, æ, ß, ...
>
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.
Bill
> 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: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? > 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.
> > 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.
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
