Skip Navigation

Overloading, part 1

I think the thing that has always bugged me about the Services menu in OS X is that I don’t use it, and I can’t see a possible universe in which I would use it. It’s just there, slowly cluttering itself up with lame-ass services provided by applications that never asked me if I gave a damn. Worse still, applications that think they’re particularly special have the option to give their service a keyboard shortcut —that is, a system wide keyboard shortcut— so that you too can have the three-fingered convenience of creating a new sticky note out of whatever is lurking on your clipboard, any time you like.

Ordinarily these shortcuts don’t harm anyone. It doesn’t matter to Camino users that Command-Shift-F sometimes performs a Spotlight search of your clipboard contents, because it’ll never do that while they’re using Camino; it’ll do what they expect it to: put keyboard focus on the toolbar’s Google search field. Why? Because the active application has precedence. If there’s a conflict between an application-specific keyboard shortcut and a Services menu shortcut, the application wins. And so it should.

But it does have consequences for the percentage of people who will, upon using Camino for the first time, express frustration that their favorite system-wide shortcut for spotlighting is broken in that browser. Putting aside the fact that there has long been a de-facto standard shortcut for search field focus that the Camino team seems intent to ignore (Command-Option-N, and it’s not just de-facto), this “sometimes it works, sometimes it don’t” game the Services menu plays, while benign, has the potential to confuse.

Confusion, however, is just the beginning. There is a rarely-occurring conflict between certain applications like MarsEdit that provide customizable keyboard shortcuts independent of the menu bar (presumably employing their own listeners see update) and applications like Acquisition, whose contribution to the Services menu can mess with those shortcuts. In this case, MarsEdit’s fully-customizable HTML insertion menu loses the tug of war with the Services menu — as those with Acquisition installed may discover when they try to “Paste Link” with Control-Shift-A, only to launch Acquisition and perform a P2P search for their clipboard contents.

While the subordination of MarsEdit’s nonstandard shortcuts sucks, it is just a technical problem that can be solved in any number of ways. Ranchero could fix the problem on their end, the user could change their shortcut for Paste Link (it’s customizable, after all), or the user could disable Acquisition’s service manually or with a bit of help. Not a big deal, if it bothers you, but it illustrates just what can go wrong when we start overloading single keyboard shortcuts with multiple uses in different contexts. Context sensitivity is useful at times (though many old school UI guys would strongly disagree), but under no circumstances should I be forced to remember just when I can and cannot not use a certain shortcut.

Update

Brent sez:

MarsEdit doesn’t have its own listener for shortcuts. What it does in the case of the HTML menu is put the menu in the toolbar of a document window and give the commands shortcuts.

Which is a straightforward thing: there’s no custom event handling code or anything going on.

My guess is that the system gives priority to the app’s menu bar, then the Services menu, and then to menus that appear outside the main menu bar.

To fix it, we probably need to implement our own listener for shortcuts. (In other words, to work around what I consider a flaw in the design of the system, we’ll need to add some custom event handling code.)

That sucks. Oh, the joys of software development.