When I first read Dan Wood’s plan for Report-An-Apple-Bug Friday, I was amused but a little disgruntled by the idea. Turns out this once long-term Apple employee has a bit more loyalty than he thought he did. Or is it just empathy? The part that turned me off was the idea that everybody should cooperate in a “mass report” of the same issue. I suppose if it’s everybody’s pet peeve, that’s fine, but I almost got the feeling that the idea was to promote some kind of bug reporting solidarity regardless of personal investment in the issue.

Although a bug with lots of “marked as duplicate” tags on it may in fact get a bit more attention than it would otherwise, it was always my impression while inside that a more significant fast-trick to fixing was how the issue ranked on the Apple Support telephone logs. Think about it. It takes a mere 30 seconds to review a bug and mark it as a duplicate. The way most groups screen bugs, there is a dedicated group member who probably has all the common bug numbers bookmarked or memorized by now. When somebody calls in to discuss a problem, it costs toll-free telephone time, and probably at a minimum 5 minutes of a telephone operator’s time. While the operator probably makes less than the bug screener, they would have to make 10 times less for the cost of just the wasted salary to match the cost of marking a bug as a duplicate.

Perhaps if this movement really is meant to be a guerrilla campaign to control Apple’s bug fixing priorities from the outside, it should be dubbed “call 1-800-SOS-APPL Friday” instead.

Nonetheless, I like the reminder to get those pesky peeves out of my head and into the system. Don’t get me wrong, I’m an avid bug reporter as-is, but I do go through slumps where I just feel too lazy to navigate the sometimes obnoxious HTML-based bug reporter Apple provides.

Today I will participate for the first time in reporting a bug that directly affects the behavior of my application, FastScripts. I am also taking Mike Zornek’s suggestion of tagging this entry with the keyword “applebugfriday.” If that causes some new readers to come on board, then “hello, and welcome!”

The bug I’m reporting is a smaller part of a larger issue which has to do with the “rights of cursor ownership.” I already have an outstanding bug report from 2003 (#3260283) which addresses the bigger issue: Apple’s unfair practice of allowing the front-most application to change the cursor even if the user’s mouse is hovering over a floating UI that doesn’t belong to that application.

Until that bug is fixed we’re left with a scenario where a certain amount of courtesy is called for when it comes to manipulating the cursor. Most applications are well-behaved in this regard, but some are ridiculously rude. PowerPlant is especially villainous in this regard. All PowerPlant apps that I’ve encountered have a habit of constantly resetting the cursor back to a plain arrow. This means that if any UI floating over the app attempts to change the cursor, it is instantaneously switched back to an arrow by the offending app. A terrible UI results for all parties involved. The floating UI doesn’t get its point across. The user gets frustrated by the flickering cursor, and the application author gets embarrassed (I wish!) by its rude over-involvement with all things cursor.

For the most part Apple’s own applications are better behaved. One glaring exception is unfortunately the one Apple application that is always running: the Finder! And that is the target of my bug, today. Thankfully, the Finder doesn’t behave quite as badly as most PowerPlant applications (though it may have at one time when it was more heavily based on that framework). What the Finder does though, is listen for changes in the state of the modifier keys (shift, ctrl, etc.), and uses that opportunity to reset the cursor to whatever it feels is correct (always an arrow in my tests). This overrides any UI that might be presented in front of it, and any custom cursor which might help the user better understand the software that they are piloting. In FastScripts, I allow the user to perform certain shortcuts by selecting menu items with certain of these modifier keys held down. For instance, to easily change the keyboard shortcut of a script, the user can select it while holding down the command key. To aid the user’s understanding that a special action will occur, I change the cursor when the key is held down. The Finder, and other rude applications, are the bane of my application’s elegant user experience.

It’s not just FastScripts that is affected by this. A great example is shipped by Apple and used by (presumably) hundreds of thousands of people per day: the Dashboard. With the Finder as the frontmost application, activate the Dashboard. Now, move your mouse to any widget which has good reason to modify the cursor. For example, select the text entry field of the Translation widget. Notice the familiar “I-Beam” cursor appears, as we would expect. Now, simply press the shift key, or control key, or caps lock. Whatever. You’ve lost your I-Beam. Worse, to get it back you’ll have to coerce the widget into resetting it by activating another widget and then switching back. It has no way of knowing it needs to reset the I-Beam – it already set it once and it knows it doesn’t need to set it again! At least, in a predictable world it wouldn’t need to.

Ideally Apple would fix the root problem, and disallow the front application from willy-nilly changing the cursor when the mouse is positioned over a window that it doesn’t own. Failing that, Apple’s own products should showcase a more respectful attitude towards cursor rights. If another application is displaying meaningful UI above the Finder, then the Finder should stop hogging the cursor! Radar #4243655.

I’m on a bit of a productivity kick lately. I’m trying to listen to the little voice in my head that speaks up when I’m doing something incredibly tedious and error-prone, and could clearly be automated.

Some people would say that spending 3 hours cranking out a script that might save you at most a minute or two each time you use it is the opposite of productivity, but I beg to differ. Yes, it may take a while to fully earn back the time I spend on such modest life improvements, but the little changes often clear the way for bigger changes down the road.

How many of you have ever stared at a folder in the Finder, teeming with files of varying types and names, and wished you could easily select by regular expression? Well, your reward for reading this blog is that as of today, you can!

I was inspired by a project of mine whose directory hierarchy was “out of control.” Since the project started out small, I had colocated all of the source files, images, documentation, reference materials, etc., in one directory. Now I’m looking at it and thinking, “gosh, I’d like to at least put all the source files in a sub-folder, but it’s drag to select every ‘.m’ and ‘.h’ file by hand.”

At first I tried to accomplish the task in AppleScript alone. Among the many things missing from AppleScript is a built-in regular expression engine, so I knew I’d have to either install a scripting component, or resort to Mac OS X’s built-in command line tools. My script started out as an AppleScript that merely called out to perl (via “do shell script”) to handle the regular expression parsing:

This worked great, but as expected, those repeated “do shell script” calls dogged performance big time. The point of this is to automate a task so that it happens in the blink of an eye. If I have to wait for a long pause, then I’ve just replaced one frustration with another!

How to avoid the delay of the repeated “do shell script” commands? I thought about spitting out the names of the files to a temporary file, and running perl just once against that file. Yeah – complicated and I don’t like to use temporary files when it’s possible to avoid them.

I decided it was time to approach the problem from the other angle. There’s no reason I can’t write the script in Perl and just call out to AppleScript as necessary to interface with the Finder. An added benefit is that I can easily use the Perl script from the command line or a script menu. I set the script up as a FastScripts Finder-specific script, and applied the keystroke “Cmd-Opt-S” as a shortcut. Now when I’m looking at a window like this:

I just hit Cmd-Opt-S to bring up this dialog, enter a regular expression:

And end up with this!

Can’t wait to get your hands on this? Feel free to download a copy of “Select Regular Expression” from the Red Sweater scripts page. Enjoy!

Update: Version 1.0.1 of the script saves and restores the regular expression you enter, so the dialog is always pre-populated with the last string you tried.

FastScripts 2.2.5 has been released and is available for download.

This update fixes a few minor bugs and adds a significant new feature: custom menu sorting. FastScripts now recognizes scripts and folders named with the “BBEdit style” organization convention, and will sort them appropriately in the FastScripts menu. For those of you unfamiliar with this convention, the gist is that if you prefix a script or folder’s name with two characters and a right-parenthesis, those characters will be stripped from the visible name of the item, but still used for sort-ordering. FastScripts also respects the folder naming suffix of “-***”, meaning “add a menu separator item.”

For example, a directory containing the following items:

is displayed in a submenu with the following appearance:

People have been asking for this feature for a long time, but it required a surprising amount of redesign, since so much of the app assumed there would always be a straight alphabetical ordering of things.

If you’re like me, you take great comfort in the presence of the Terminal in Mac OS X. I love a great GUI, but the fact is that many tasks on the Mac are still best accomplished from the behind the wheel of a shiny new pseudo-tty.

Usually I get the need for command-line access to an object just as I’m browsing near it in the Finder. In the bad old days, I would laboriously open the Terminal, type “cd “, then drag a copy of the item I’m interested in to the Terminal, and if it was a file, torturously edit out the leaf-name part of the path before hitting return!

Grr! I’m getting stressed out just thinking about it! Things have gotten better for me since I sat down and wrote a handy script to accomplish all of this for me. My Terminal At Location script does just what its title implies: opens a new terminal window with the current path set to the object of your current Finder-fixation. You can download this script from the Red Sweater AppleScript Page.

I have this script configured as an application-specific keyboard shortcut for the Finder. Whenever I need to “switch to command-line mode” I just hit Cmd-Shift-T and I’m off-and-running. If you don’t already have an application-specific keyboard shortcut tool for quickly running AppleScripts, then allow me to give my unbiased (ahem) endorsement of FastScripts. Create a Finder-specific scripts folder, drop the script in, and select it from the FastScripts menu while holding down the Cmd key to quickly set your desired shortcut.

If you spend a lot of time switching between the Finder and the Terminal, you will not forgive yourself for failing to set up a script like this sooner.

Update:Version 1.0.1 of the script fixes a bug that caused terminal parsing errors for paths with funny characters in them.