Doug, I mentioned my concerns as well, back in 7.0, that hotkeys would become a concern someday.
They added the script menus in 7.1, and I myself, while admiring the elegance of the multi-key layering, prefer the menu control of an application to that of having to remember dozens of different hotkey combinations. If you're going for the "sparkling user experience" as Ron puts it, I suggest considering if each individual function can be controlled with a menu choice rather than a hotkey. Of course you could do the same thing with a custom help dialog, but then that requires the user to master a more complex environment to make a configuration change. Chip -----Original Message----- From: Doug Lee [mailto:[email protected]] Sent: Wednesday, September 01, 2010 2:56 PM To: [email protected] Subject: Re: precedence of set file and script hotkeys 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] -- Doug Lee, Senior Accessibility Programmer SSB BART Group - Accessibility-on-Demand mailto:[email protected] http://www.ssbbartgroup.com "While they were saying among themselves it cannot be done, it was done." --Helen Keller
