Comments on: FastScripts 2.3 Beta Release Official blog of Red Sweater Software Sun, 17 May 2015 00:38:21 +0000 hourly 1 By: Daniel Jalkut Fri, 08 Sep 2006 12:12:15 +0000 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.

By: Roger Purves Fri, 08 Sep 2006 06:47:41 +0000 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

By: Daniel Jalkut Thu, 07 Sep 2006 20:48:46 +0000 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!


By: Roger Purves Thu, 07 Sep 2006 19:02:56 +0000 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

By: Daniel Jalkut Wed, 06 Sep 2006 03:10:22 +0000 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 :)

By: sjk Tue, 05 Sep 2006 23:10:29 +0000 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.

By: Doug Mon, 04 Sep 2006 03:32:39 +0000 Daniel,

One thing I have noticed is that the menubar icon doesn’t highlight when a script it running. Minor point.


By: Doug Mon, 04 Sep 2006 01:34:58 +0000 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.