I implemented this sort of layered key sequence thing for another
screen reader, for several apps. Largely, and to my surprise, it did
not take off; but I still like and use the idea sometimes. My system,
for anyone wanting a full picture of something, works like this:

There's a single prefix keystroke, after which you can type other keys
that do one of the following:

- Execute a function and leave the sequence,
- Execute a function and stay at the current sequence level,
- Go to a deeper sequence level (like a submenu), or
- Exit the sequence because they are not part of this level.

The Esc key is the official way out of the sequence from any level.

There are also the following keystrokes at all levels:

- Tab and Shift+Tab cycle through available commands at this level and
  speak descriptions,
- Enter executes the last command described by Tab or Shift+Tab,
- Esc exits the sequence, as said earlier.

Finally, if you type the prefix key twice in a row, you get the
keystroke sent once to the application in focus.

Examples from my Skype scripts, where the default prefix is the left
bracket key ([):

[t followed by a digit: Focus a specific screen area.
[t1 Go to the Contacts list.
[t2 Go to the Conversations list.
[m Miscellaneous commands.
[md Turn the dial pad on or off in a call.
[me Go to the edit box in a chat window.
[n Notification commands.
[n1 Read the most recent notification and stay at this level.
2 after the above reads the next most recent.
Esc exits the sequence when you're done reading notifications.

On Fri, Jun 05, 2015 at 09:18:24PM -0400, Chip Orange via Scripting wrote:
Hi Jim,

One of your many good points is doable right now by any developer: if I
wanted, I could let the user define the primary hotkey for my app (say shift
h) then as soon as they hit that, I would define in my program a whole list
of secondary hotkeys (maybe just ordinary letters); you could intercept the
onkey event so that if they didn't hit one of your secondary hotkeys, it
just canceled it.  Similar to Rod's idea, but you could define layers of
hotkey sequences for your apps this way and only have the user be able to
change (or have to change) the primary hotkey; all the others need never be
changed, since they would never conflict with any other app.  Therefore,
it's no problem that the hotkey manager doesn't write them to the .ini file.

I would not feel like I needed to allow the user to change these secondary
keys since there was no possibility of conflict, but if you did feel so
inclined, it would be simple enough for you to write your own dialog which
did this just for your commands in your app.

I really like this two-key idea, for complex apps, where the user only needs
to possibly change the primary hotkey which begins them all.  I think I'll
offer it as an option in Remind Me Where so that if they select, all the
secondary commands are just normal keystrokes; so they could hit the RMW
primary command and then just hit l for look around, s for search, g for get
directions, and so on.

Yes Jim, I do think I remember Windows Bridge having command sequences like
this, and now that I'm up to about 11 hotkeys, I need to stop using them all
up and just switch to this system; because as David says, most users don't
want to go to the app menu (I only meant it to help them out when they
couldn't remember all the hotkeys for a seldom user app).

Chip


-----Original Message-----
From: Scripting
[mailto:scripting-bounces+lists3717=comcast....@lists.window-eyes.com] On
Behalf Of Jim Grimsby JR. via Scripting
Sent: Friday, June 05, 2015 3:58 PM
To: 'Chip Orange'; 'Window-Eyes Scripting List'
Subject: RE: Double Hotkey, and Hotkey Manager

This is why window-eyes needs to do a better job working with prefixes.  For
example the numpad insert should be a prefix as well as the standard insert
and the caps lock and left and right windows.  More prefixes gives users
more alternatives.  Not only this but one shot commands.  For example for
hot spots caps h then control  a for add hot spot and control  m for manage
hot spots.  Tab could be used to move threw the keyboard command to learn
the command or just find the one you want quickly.  Once the command is
performed the command is exacuted and then you are returned to normal
functionality. 
Window-eyes commands should be moved over to the numpad when ever possible
to free up command space on the keyboard and to avoid conflicts with normal
aplacation use.  this is why the problem of shift insert need to be fixed.
Double clicking of keys should also be supported.  This is nothing new chip
you may remember that many of these ideas were used in window bridge 2000.
Another good idea is to be able to define the order in witch prefixes are
pressed.  For example if you press shift control  the program gets the
function where if you press control  shift the window-eyes gets it.  Another
option would be that if you press the order in one way one thing happens if
you press it in another something else happens. 
Window-eyes should also allow for apps to add functionality to the
window-eyes user interface. Defining hot keys for apps should be done the
same way you do it for the internal command for window-eyes it self.  Verces
going in to a manager for each app. Thing like controlling  progress bars
auto complete should be done from verbosity.  This has always been a
weekness of window-eyes apps they don't feel like the program it self.  They
feel and look like external programs verces adding functionality to the
screen reader it self.  I mean they do clearly add the functionality but it
doesn't feel like you are working with the same program. For example you
work with ms word that feels like a part of window-eyes where if you want to
do something with skype app you have to work with an external program.



-----Original Message-----
From: Scripting
[mailto:scripting-bounces+jgrimsby=roadrunner....@lists.window-eyes.com] On
Behalf Of Chip Orange via Scripting
Sent: Friday, June 05, 2015 11:36 AM
To: David; Window-Eyes Scripting List
Subject: RE: Double Hotkey, and Hotkey Manager

I know what you're saying David (I think) ... we're being swamped by too
many hotkeys for too many apps, it's hard to come up with unique ones, and
with meaningful combinations which can easily be remembered.

In my most recent app, I've tried to encourage the user away from hotkeys
and to try choosing app menu choices for those functions which aren't
obviously tied to whatever window and/or control the user is interacting
with.  I've still defined hotkeys for all of my app menu choices, but I am
counting on the user to decide what they should be if they really would
rather use hotkeys; I simply picked out a group I thought wasn't being used
yet.  I can no longer guess what combination will be meaningful, as they all
it seems are already in use.  My documentation suggests that they undefine
the hotkeys which they aren't using, in order to prevent conflict.

One other choice we have is a hotkey which brings up a primary window for
our app, which contains all of its functions as menus, buttons, whatever
(very similar to the WE main window).  This lets the user only have to
remember one primary hotkey, and then all the others will only be active
hotkeys or shortcuts when the main window for your app is active.

I think we'll have to all start to use the app menu choices or the main
control window in the future when we want to give users global access to our
apps; it's just getting too crowded for every app to have its own collection
of global hotkeys.  Hotkeys which are program-specific however, they
shouldn't be as much of a problem; there's at least room for overlap.  
It will still be difficult for the user to remember however that perhaps
control-shift-A does one thing in Outlook, and does another for the app for
GoldWave for instance.

Chip




Chip Orange
Florida Public Service Commission
Computer Systems Analyst
850-413-6314


-----Original Message-----
From: Scripting
[mailto:scripting-bounces+corange=psc.state.fl...@lists.window-eyes.com] On
Behalf Of David via Scripting
Sent: Friday, June 05, 2015 12:45 PM
To: GWScripting
Subject: Re: Double Hotkey, and Hotkey Manager

OK. Wish there was a chance for a user to define double-keys for any feature
in the hotkey manager. As more and more apps become available, and a user
may want to have his apps intuitive, even when comes to hotkeys, double-keys
will be a miss.

Let me give you but one more example, in addition to the one Chip gave. 
Say you want one hotkey for the Time, and another for Date. Other screen
readers have features split that way. It is no trouble in hard-coding this
in Win-Eyes either. Yet, should the user want to redefine to a more
convenient hotkey - for him - it is impossible, the way things stands today.
Or, what about an app that would perform a limited action when the hotkey is
pressed once, but a more advanced version of the job when the hotkey is
doubled. To a user with several apps, it would be far more comprehenble, if
the hotkeys could be grouped,according to somehow similar operation. And
with the hotkey manager in place, it really should have been possible for an
app to have double-hotkeys, and let the user redefine them as he wanted.
Whether he wanted another double-hotkey, or even if he wanted an existing
double to be split into two totally separate single-hotkeys.

Something for the developing team to put on the wishlist?


David

On 6/4/2015 12:49 AM, Chip Orange wrote:
> Hi David,
>
> As I understood it, A I never meant for you to be able to define a 
> single hotkey as being a double press of a certain key.  That is, 
> their only intent was that you could add additional functionality to 
> your basic hotkey by allowing the user to press it twice (so, one 
> press reads something, then two might spell it instead of reading it).  
> Their intent however was that the spell function in this example, was 
> always designed to be the second press of the basic hotkey.  So, if 
> the user changed the basic hotkey, then it should be made clear in the 
> documentation that this secondary function would just be a second
immediate press of whatever this key was.
>
> If you have in mind two unrelated functions, which you may want the 
> user to be able to assign to two unrelated hotkeys, then I think you 
> cannot use the second press feature for either of them (or the user 
> cannot); this can only be something you program in, and make clear in 
> your docs, if you want the second press of a hotkey to do something.
>
> It may not be what you want, but I hope this at least clears it up a bit.
>
> Chip
>
>
> -----Original Message-----
> From: Scripting
> [mailto:scripting-bounces+lists3717=comcast....@lists.window-eyes.com] 
> On Behalf Of David via Scripting
> Sent: Wednesday, June 03, 2015 6:05 PM
> To: GWScripting
> Subject: Double Hotkey, and Hotkey Manager
>
> Listers,
> Sorry for the wrong term, but my memory fails me, as to the correct 
> term. I am wondering if there has been any further develop on a lack I 
> found earlier.
>
> Say your app has a hotkey that needs to be pressed twice within a 
> second or so - Like Alt-F12, Alt-F12 - to perform a certain task. Last 
> time I attempted to incoporate such a hotkey in my project, I found 
> that it did not work well with the hotkey manager. You can make this 
> work first hand, when releasing the app. But if the user wants to 
> redefine the hotkey - say to Ctrl-F12, the hotkey manager will 
> redefine it to only a SINGLE press of the hotkey - meaning that the 
> app will react upon the first press of the hotkey.
>
> Thing is, I have an app  here, where I want function1 to take place 
> when the hotkey is pressed once, and only once. Function2 should kick 
> in, when the user double-press the same key-combination. Hope this 
> makes sense. But how can I work this out, so that the user can 
> redefine to any other key-combo, even if he wants a 
> Single-/Double-version of another key-combo. Like in the example above.
>
> Sorry for a messy message, but hope I came through clear enough that 
> someone could please let me know, if there is any workaround here. Or, 
> is this not possible to achieve the way things stands as  of current?
>

_______________________________________________
Any views or opinions presented in this email are solely those of the author
and do not necessarily represent those of Ai Squared.

For membership options, visit
http://lists.window-eyes.com/options.cgi/scripting-window-eyes.com/corange%4
0psc.state.fl.us.
For subscription options, visit
http://lists.window-eyes.com/listinfo.cgi/scripting-window-eyes.com
List archives can be found at
http://lists.window-eyes.com/private.cgi/scripting-window-eyes.com
_______________________________________________
Any views or opinions presented in this email are solely those of the author
and do not necessarily represent those of Ai Squared.

For membership options, visit
http://lists.window-eyes.com/options.cgi/scripting-window-eyes.com/jgrimsby%
40roadrunner.com.
For subscription options, visit
http://lists.window-eyes.com/listinfo.cgi/scripting-window-eyes.com
List archives can be found at
http://lists.window-eyes.com/private.cgi/scripting-window-eyes.com

_______________________________________________
Any views or opinions presented in this email are solely those of the author
and do not necessarily represent those of Ai Squared.

For membership options, visit
http://lists.window-eyes.com/options.cgi/scripting-window-eyes.com/lists3717
%40comcast.net.
For subscription options, visit
http://lists.window-eyes.com/listinfo.cgi/scripting-window-eyes.com
List archives can be found at
http://lists.window-eyes.com/private.cgi/scripting-window-eyes.com

_______________________________________________
Any views or opinions presented in this email are solely those of the author 
and do not necessarily represent those of Ai Squared.

For membership options, visit 
http://lists.window-eyes.com/options.cgi/scripting-window-eyes.com/doug.lee%40ssbbartgroup.com.
For subscription options, visit 
http://lists.window-eyes.com/listinfo.cgi/scripting-window-eyes.com
List archives can be found at 
http://lists.window-eyes.com/private.cgi/scripting-window-eyes.com

-- 
Doug Lee, Senior Accessibility Programmer
SSB BART Group - Accessibility-on-Demand
mailto:doug....@ssbbartgroup.com  http://www.ssbbartgroup.com
"While they were saying among themselves it cannot be done,
it was done." --Helen Keller
_______________________________________________
Any views or opinions presented in this email are solely those of the author 
and do not necessarily represent those of Ai Squared.

For membership options, visit 
http://lists.window-eyes.com/options.cgi/scripting-window-eyes.com/archive%40mail-archive.com.
For subscription options, visit 
http://lists.window-eyes.com/listinfo.cgi/scripting-window-eyes.com
List archives can be found at 
http://lists.window-eyes.com/private.cgi/scripting-window-eyes.com

Reply via email to