FastScripts 2.3 Beta Release
September 3rd, 2006I imagine FastScripts users might be feeling a little neglected, what with all the attention I’ve been giving FlexTime over the past several months. But worry not, I’ve been collecting improvements for FastScripts all along, and am nearly ready to release a 2.3 version of the app.
It’s actually pretty close to ready for shipping. But it would be nice to have a little 3rd party testing, because quite a bit has changed. Click here to download the 2.3b2 release.
The most “scary to me” parts that have changed are all infrastructure-level. At the user feature level there were a bunch of minor enhancements and these more substantial changes:
- Grayscale Menu Icon. For years a vocal minority has copmlained about the colorful FastScripts icon being both distracting and clashing with the appearance of Apple’s icons. They finally convinced me to agree with them. I know some people will miss the old icon, so I’ve left it in as a preference choice. The grayscale icon will probably see a few minor tweaks before 2.3 ships, so let me know what you think of it.
- Modifier-free Shortcuts. Up until now FastScripts has only supported keyboard shortcuts where some modifier key is held down (except for the special case of Function Keys). I was hesitant to add support for plain keystrokes, because it’s easy to imagine users getting themselves into trouble. But there are a few examples where overriding a bare keystroke (usually in an application-specific context) is a useful thing to do. Just beware that you won’t be able to type that keystroke into any text after you’ve set the shortcut. FastScripts will warn you when you attempt to set such a shortcut, so don’t worry too much.
- Preference Window Overhaul. Well, maybe overhaul is too strong, but things have been shaken up. I’ve added a new “General” tab to house a new UI for controlling whether FastScripts is in your Login Items or not. That feature is long overdue. I’ve also moved some other preferences into that pane, where they seem better suited.
I’m really looking forward to hearing your impressions. Please let me know especially if you run into any problems.
September 3rd, 2006 at 6:34 pm
Daniel,
I like the gray icon, but I agree with you that it needs a few tweaks yet. (It seems a little thin toward the bottom compared to the color one, or perhaps the perspective is skewed). Modifier-free shortcuts call to my inner VIM, although I’m not sure where I’d actually use them in most apps. I’ll keep an eye out for any problems.
Doug
September 3rd, 2006 at 8:32 pm
Daniel,
One thing I have noticed is that the menubar icon doesn’t highlight when a script it running. Minor point.
Doug
September 5th, 2006 at 4:10 pm
Two things:
Defining a shortcut containing characters typed using the shift key will display in FastScripts menus/preferences with “shift-” symbol pairs. For example, a control-) shortcut appears as control-shift-0.
Without using an unsupported menu extra hack, I suppose we’ll still be stuck not being able to drag the menu item further right to avoid it being temporarily hidden by wide app menus on narrow displays? In that case I might prefer having a preference permanently hide the FastScripts menu icon and just keep Apple’s Script Menu icon in the menu bar… although on second thought that might not be such a good idea for a couple reasons.
September 5th, 2006 at 8:10 pm
Doug – thanks for the feedback. The great news is that I have a top-notch icon designer helping out (it’s my lucky week) and the icon will be made dramatically better. Thanks for the note about the menu item not highlighting. I must have mucked something up along the way.
sjk: Interesting observation. I don’t think I had noticed how strongly Apple encourages the “no shift indicated” behavior you’re describing. I see now that if I try to set shortcuts on menu items in Interface Builder, it refuses to let me define a shortcut like “cmd-shift-9” as anything other than “cmd-(“.
However, I think this may be more a sign of Apple’s own inconsistency than anything. I personally find it very confusing when anybody leaves out any of the required modifiers in keyboard shortcut. For instance, I sometimes notice people describing two shortcuts “cmd-f” and “cmd-F”. To me, this is just counterproductive.
I thought I might find out whether Apple had an official position on this (aside from its behavior in IB), and what I have mostly observed is that Apple rarely uses shortcuts that involve keys with different values when shifted. But there are some important examples listed on the Apple shortcuts quick reference. Notice that in that document all such shortcuts are described explicitly with the shift-key symbol included. Venerable shortcuts like “cmd-shift-3” for screen capture would in fact look rather unfamiliar as “Cmd-$”.
Another example where Apple encourages the same behavior as FastScripts is in its own “Keyboard Shortcuts” pane in System Preferences. Notice that when you add a keyboard shortcut to some menu item here, it is shown with the shift-symbol as in FastScripts. And when you view the chosen shortcut in the modified application, it maintains that same shift-nomenclature.
So … I think it’s a bug that Apple allows for two nomenclatures of the same keystrokes to be represented in a menu item. And it’s unfortunate that they haven’t made a clearer statement as to which of the two forms is preferable. I certainly think that when indicating a keystroke, all modifier keys should be spelled out explicitly. But I’m open to hear more argument to the contrary :)
September 7th, 2006 at 12:02 pm
to Daniel Jalkut:
Does the “Modifier-free Shortcuts” include use of the “enter” key in the following
manner? Suppose I have a TextEdit document open on the desktop. I select some
text in the document, then press the “enter” key–nothing else. As a result,
an AppleScript goes into action and does something with the selection. Is this
possible? (I would like the same functionality for the “enter” key in any reputable
text handling program that has an AppleScript dictionary rich enough to do various
things with text.)
If the answer is “yes”, could you say anything about how your program works
with applications. Doesn’t an application have “first rights” to keystrokes?
Where does FastScripts intervene? If these questions seem confused, they
probably are. It is just that I am a little concerned that FastScripts might reach
so deeply into OS X that it could lead to trouble later.
I drop in on your blog about twice a month and really enjoy reading it.
Thank you,
Roger Purves
September 7th, 2006 at 1:48 pm
Hi Roger – glad you like the blog!
What your describing is definitely possible – theoretically. The very specific problem is that the enter key is among the keys that, in FastScripts’ shortcut editor, get interpreted as something other than input. So it would be impossible (as of now) to actually tell FastScripts that enter was the key you wanted to use. I think the advent of single-key shortcuts makes this more problematic, so I’ll think on how I might remedy this. Perhaps I’ll continue to interpret these special keys (esc to cancel, return/enter/tab to end editing), but provide a second “detailed editor” sheet that would allow a more visual and complete editing of the keystroke.
As to your question of how FastScripts accomplishes this, it’s all done in a very “above the board” manner. The Carbon programming API from Apple provides legitimate means for applications to install “hotkey handlers” that are processed on all keystrokes, before they are handed to a specific application. So the hazard is not in any instability in your system, but simply in accidentally replacing a useful keystroke in some app with one of your own choosing.
Hope this helps!
Daniel
September 7th, 2006 at 11:47 pm
to Daniel:
Thank you for your quick and considered reply.
I had a vague impression that the “hotkey handlers”
were somehow limited to key combinations
and that a single keystroke of the “enter” key
was out of bounds. So, unless I am reading
too literally, the phrase:
“processed on all keystrokes”
in the second paragraph of your reply implies
that the creators of Text-Edit, TextWrangler,
Mariner Write (say) could, if they wished, all have
a single press of the “enter” key do different
things. (I am not saying this is would be a good
idea, just trying to pin down what is possible.)
I hope I’ve read you correctly.
Roger Purves
September 8th, 2006 at 5:12 am
Roger: Yes, you’ve read me correctly. And in fact, they could all do that without the global hot key mechanism, because the vast majority of keystrokes (enter included) are passed to the application itself before it gets dispatched down to the text view or whatever it is that ultimately handles it.