I'll take this opportunity, in case I haven't before, to defend a
concept I've experimented with, though not in Window-Eyes, for years.
I call it MultiKey Command Sequences (MKCS). It's sure not a new idea
at all, but it's different than what any Windows-based screen reader
I've seen does now (at least without a lot of scripting).
The idea is that you let the user pick a keystroke that parents all of
your script commands, then you set up a structure under that. I tend
to use the left bracket for the in-focus application and the right
bracket for out-of-focus ones, though in the Window-Eyes model of
running scripts for all running apps at once, this approach is
insufficient.
The point of the system is to reduce the number of keystroke conflicts
that can exist. This idea has also been called "layering." In
programming terms, it's like namespace control.
Once the user presses the key for your script set, your script must
decide what to do with all subsequent keys. This breaks down into
deciding what if anything to do in response to the key, and whether to
stay at that layer, go to another layer, or exit the whole sequence.
As examples, you would want arrows to stay in the current layer but a
key that invokes a dialog to exit the sequence. As a rule, when I
design a structure of this sort, I make a double press of the first
key just pass the key once through to the application. That makes it
practical to use simple keys, rather than multiple-key combinations,
as the first key. I might, for example, review messages in Skype by
pressing a left bracket, then the letter c, and then arrows to read at
will, and finally Esc to exit the sequence and return to the
application. If I need to type a bracket in a Skype chat, I just tap
it twice instead of once.
I admit this approach takes much more thinking through, and probably
coding, than the normal single-key-combination approach to key
assignments. I think, though, that particularly in Window-Eyes, key
conflicts are going to become more and more of a problem without
something like this.
On Wed, Sep 01, 2010 at 02:35:40PM -0400, Ron Parker wrote:
The current behavior is that whoever registered the hotkey first gets
it.
Given that that's not
(A) the best possible behavior in this circumstance (for example, it
might be nice if application-specific scripts got hotkeys before
global scripts) nor
(B) necessarily the most optimal way to handle the dispatching (some
sort of hashing container might turn out to have better performance
characteristics than whatever we're using now)
I think it's probably not a great idea to count on that remaining so
in the future.
Generally speaking, it's best if your script allows its hotkey
assignments to be configurable, so that the end user can choose keys
that work for them and that don't conflict with other scripts that
they use. Keep in mind that that approach has got some accessibility
arguments going for it, too: not everyone has the flexibility to hit
shift-ctrl-windows-insert-7.
Something else you might keep in mind if you're aiming for a truly
sparkling user experience from your global script is a feature akin to
the one in Progress Indicator that allows the end user to turn off
your script when certain windows or applications are active. You'd
probably want to unregister your hotkeys in such a situation (or,
alternatively, use the keyboard events instead of registered hotkeys.
Just be mindful of the caveats inherent in working with those
low-level events.)
By the way, to answer the obvious next question: registered hotkeys
always take precedence over keyboard event listeners (with the same
caveats that Aaron mentioned - it's true now, but we reserve the right
to change it.) So if you want your global script to always be behind
someone else's local script that uses registered hotkeys, roll your
own hotkey processing with keyboard events. Just remember that Queue
is your friend, and you should use it liberally in any
keyboard-event-based scheme.
On 9/1/2010 2:16 PM, Chip Orange wrote:
Aaron (or anyone),
I'm just curious, if you try to define a hotkey which is already
defined by another script, will it throw an error? if not, which
script will take precedence (the last, the one which is application
specific, any rules)?
thanks.
Chip
_________________________________________________________________
From: Aaron Smith [[1]mailto:[email protected]]
Sent: Wednesday, September 01, 2010 11:15 AM
To: [2][email protected]
Subject: Re: precedence of set file and script hotkeys
On 9/1/2010 10:12 AM, Cory Samaha wrote:
If I want to ship a script package, is it safe to assume that script hotkeys wi
ll
always take precedence over set file hotkeys, or is it a better idea to ship
a set file with the script which will undefined these hotkeys?
For Window-Eyes 7.X (and probably 8.0), you're guaranteed that script
hot keys will take precedence over set file hot keys. That probably
won't change in future versions, but it could if we come up with a
good reason. So we don't want to commit to this always being the case
forever. But it is the case for now.
Aaron
--
Aaron Smith
Product Support Specialist * Web Development
GW Micro, Inc. * 725 Airport North Office Park, Fort Wayne, IN 46825
260-489-3671 * gwmicro.com
To insure that you receive proper support, please include all past
correspondence (where applicable), and any relevant information
pertinent to your situation when submitting a problem report to the GW
Micro Technical Support Team.
References
1. mailto:[email protected]
2. mailto:[email protected]
