This is the first of a series of posts (two) on the method -[NSWorkspace openURLs: withAppBundleIdentifier: options: additionalEventParamDescriptor: launchIdentifiers:], described in the NSWorkspace Class Reference. The first post will consist entirely of naming the method, because just typing it has given me carpal tunnel syndrome.
My cat graciously offered to type, so we’ll press ahead. Vienna has a built-in WebKit browser that allows you to follow links in a feed without switching to another app. There is a preference to choose whether to open links in Vienna or in your default web browser (in my case, Safari). Opening an array of URLs in your default web browser can be accomplished by calling the above mentioned method with the parameter withAppBundleIdentifier: set to nil.
Occasionally I want to override Vienna’s link opening preference. For example, I might want to bookmark some pages in Safari while still doing most of my web browsing in Vienna. (Note to self: implement feature in Vienna to add page to bookmarks.) My very first contribution to the Vienna project was a patch to override the preferred link opening behavior with a keyboard shortcut. I used the shift key, because at that point the option key was reserved for another purpose. The patch would do the opposite of your preference when you shift-clicked a link in the article pane or typed shift-return in the articles list. In other words, it would give you chicken salad, on rye, untoasted, and a cup of tea.
Using the shift key for this feature was a mistake, I later discovered. I received a bug report in the forum from a user who had minimized a Safari window to the Dock. When the user pressed the shift key in Vienna to open a link, the page did indeed open in Safari … extremely … slowly. My new Vienna feature had inadvertently activated the Mac OS X super-slow-motion effect for opening minimized windows. (The only purpose of this effect, as far as I can tell, is to mildly impress Windows users.) I faced another apparent example of relativistic weirdness, as if the shift key created time dilation by accelerating the rest of the system to near light speed, leaving Safari to lumber along like a gorilla. You maniacs! You blew it up! Super slowly!
To make a long story even longer, I fixed the bug in Vienna by switching the modifier key from shift to option. All recent builds of Vienna use the option key to override the browsing preference. My advice to you is to avoid using the shift key in your application as a modifier to open external links. Thank you very little.
First up I just wanted to say I’m loving your work and have been very happy since making Vienna my RSS reader of choice. (A GTD choice to stop Safari enticing me away from real work by notifying me of new feeds to read.)
There are two features which would make it totally unnecesary for me to open a page in Safari. The first is some way to send the current page to del.icio.us. I find so many new sites through RSS feedsa and that would really help.
The other one is to give the option key modifier when you right click on a link to change “Download Linked File” to “Download Linked File As…”.
I know this isn’t the right place for this kind of feedback, but I’ve been reading your blog for a few weeks now and wanted to give somethign back.
Sorry while I’m on, one last big wish would be to make it possible to synchronise data between two machines. So often I’d like to catch up with my RSS feeds away from my work machine and that would make it possible.
You maniacs! You blew it up! Super slowly!
There must be something in the air today.
Thanks for the feedback. I’m sorry, I can’t provide Vienna support in the comments of my blog. The appropriate place for Vienna feature requests and bug reports would be the forum. The most important reason why you should post there is that I’m not the only member of the Vienna project. Posts in the forum will be seen by Steve, other developers, potential developers, the Vienna support staff, and Vienna users, whereas posts in my blog comments might not be seen by anyone but me. Furthermore, if all the support requests are in one place, the forum, they’re much easier to track and search. Thus, requests there are more likely to be acted upon than requests here. Also, readers of my blog might not be interested in wading through support requests and the follow-up discussion they require.
Scott, that is a strange coincidence. You know what they say: human see, human do.