And that’s just it. Firefox 3’s shortcomings as a Mac app are behavioral, too.

I’m giving Firefox for just reason that Gruber highlights later on in his piece — improved memory management. I’ve only got 1 GB of RAM on my PowerBook and my computer’s performance would noticeably drag when running Safari for extended periods. Conversely, I’ve noticed little-to-no slowdown with Firefox running.

That said, Gruber’s definitely right that Firefox isn’t a particularly good Mac app. In addition to his list of issues, there are two that I’m finding bothersome.

• Doesn’t Respect RSS Reader Setting — Apps like Safari, NetNewsWire, and others are capable of registering as the default feed reader and Safari will happily pass feed URLs over to the selected reader. This makes it simple to subscribe to new feeds. Firefox, however, doesn’t honor this setting, instead displaying the feed contents in a new tab/window.

  Update: Turns out that while Firefox won’t respect the default system feed reader, you can configure Firefox to use NetNewsWire or your other feed reader of choice. The Applications panel in the preferences lets you (appropriately enough) configure external applications for different content types. I’d originally looked here for some sort of setting, but missed the Web Feed option among all the audio and video formats.

  

  Firefox doesn’t seem to auto-detect the feed readers installed on your system, but you can point it at NewNewsWire and it seems to work as expected. In addition to supporting external applications, Firefox goes one step further and allows you to specify web-based feed readers, like Google Reader or My Yahoo. So, as is often the case with Firefox, the desired functionality is present, but not necessarily Mac-like. (Thanks to John Gruber for pointing this out to me.)

• Doesn’t Use System Keychain — Old news, I know, but I’ve been retyping a bunch of passwords lately and I’ve occasionally had trouble remembering which password is associated with which site. I have the choice between trying a number of passwords till I find the right one or firing up Keychain Access and looking for the appropriate record.

  On the plus side, the save password display in Firefox is quite nice. The display is similar to the new search bar in Safari and hangs around after the password-protected page has been loaded. If you’re not sure whether you’ve entered the right password, you can defer saving the password until after you’ve confirmed the validity of the password. Definitely an improvement of Safari’s ask, then process approach.

I’m not saying that Firefox isn’t a good web browser. However, it’s very likely that I’ll switch back to Safari once I get a computer with more resources.

One thing I’ve been meaning to do for a very long time is talk a little bit about the state of my other popular Mac app, Cocoalicious.

I’m glad to see Buzz getting Cocoalicious up and running once more, and I’m not just saying that because I contributed to the next release.

…but they added back folder sharing, a feature never seen in Mac OS X, even though it was widely used in Mac OS X 9 [sic] and releases before that.

Combined with Data Detectors, it looks like we’ve got new leaders in the clubhouse for the coveted title of “Last Classic Mac OS Feature to Migrate.”

Anybody think of any remaining features which might make the jump in the future?

Michael added support for setting the source URL to the post’s permalink. Among other things, this activates the Open Source URL command in the Record menu.

If you’ve got my capture script installed in EagleFiler’s Application Support folder, you won’t see this new functionality — EagleFilers gives precedence to user-installed scripts over its own bundled scripts. If you’re just using the capture script as I originally posted it, you can delete my script. You’ll gain the source URL functionality without losing anything.

If you’ve customize the capture script to better suit your workflow, you can apply Michael’s change to add support for setting the source URL. Just replace this line:

return {{|path|:tempPath, |title|:theTitle, tags:theTags, |deleteWhenDone|:true, |note|:theNote}}

with the following (sorry about the long lines):

if thePermalink is not "" then
    return {{|path|:tempPath, |title|:theTitle, tags:theTags, |deleteWhenDone|:true, |note|:theNote, |sourceURL|:thePermalink}}
else
    return {{|path|:tempPath, |title|:theTitle, tags:theTags, |deleteWhenDone|:true, |note|:theNote}}
end if

While checking out the change notes for the updated EagleFiler, I noticed the following line:

You can now modify capture scripts while EagleFiler is open without having to relaunch for it to notice the changes.

Thank you. Thank You! ThanksYouThankYouThankYouThankYou!

(Can you tell I hit this issue while writing the original capture script?)

Oh, did I say thank you?

I’ve been playing around with an updated capture script on my own system, but I’ve been hesitant to post it because it relies on components that are part of a stock Tiger installation. I want to check out whether the situation is any different when running Leopard. I’m not sure when I’ll get around to upgrading, though.

1. The new raoli.com: all capture scripts, all the time.

The solution is to rename the capture script from com.red-sweater.marsedit.applescript to com.ranchero.MarsEdit.applescript. Once you do this, EagleFiler will recognize the older version of MarsEdit.

You’ll also need to comment out or delete the two lines in the script that begin with if theVersion ≥ 2. As the line implies, the functionality is only present in the newer version of MarsEdit. I had assumed that including the conditional statement would allow the script to run with older versions of MarsEdit, but it would appear that I was wrong.

With MarsEdit 2.0’s release, I’ve decided to re-evaluate my post management scheme. Previously, I created my posts in BBEdit, then moved them over MarsEdit via an AppleScript. I did this because I wanted to have copies of my posts archived on my hard drive and not lost whenever I refreshed my weblog in MarsEdit. A downside to this approach is that I end up underusing MarsEdit’s Draft’s functionality — I’d either keep the BBEdit window open the whole time I was working on a post or I’d save the post to my Posting directory and have to remember finish editing it at a later date.

My app tool-chain has shifted a bit over the last 3 years, so I now have a few more options at my disposal. One of those is EagleFiler. My new workflow is to compose and post in MarsEdit, then move the completed post of to Eagle Filer. To facilitate this, I’ve written an EagleFiler capture script for MarsEdit — to archive my post, I simply need to hit F1.

The script’s a bit long to include here, so I’m just going to post it for download.

Download MarsEdit Capture Script

To use this script, save it to ~/Library/Application Support/EagleFiler/Capture Scripts/, creating the last folder if necessary.

There are a few notes about what information is available for capture. First, you can’t capture a draft from the main MarsEdit window, only from the individual post window. Second, drafts which you have saved locally will have a value for date published. I believe this is the date the draft was first saved. Third, posts captured from the post window will not have a permalink value. Hopefully, future updates to MarsEdit will allow me to rectify at least a few of these.

There’s certainly room for some individualization in this script. Though I’ve stripped out the modification for public usage, my personal copy of this script adds some custom tags to each posting and sets BBEdit as the file creator. Another modification I’ve seen is adding the category information to the text of the posting. Additionally, you could add support for creating EagleFiler tags out of post keywords in addition/in place of post categories. Since Wordpress doesn’t support keywords, I didn’t implement this.

If you do edit the capture script after installing it, you’ll need to restart EagleFiler so the application will see the changes.

I wrote and tested this script for use with Wordpress blog. As far as other blogging packages are concerned, the script appears not to fail, though I can’t guarantee it’ll actually work.

If anybody has trouble with this version, let me know.

What’s New:

• Mail Headline should no longer refuse to convert HTML that contains non-ASCII Unicode characters.
• No longer prepend “Fwd: ” to email subject.
• Links are included after the respective paragraphs instead of the end of the article.

As always, you can download Mail Headline directly or get more information from my AppleScript page.

Mail Headline is a plain-text replacement for the Mail Contents of this News Item command that’s capable of supporting multiple email clients. The contents of the news item are processed with Aaron Swartz’ html2text and converted to Markdown-formatted text. The currently supported email clients include Mailsmith, Entourage, and Mail (if you prefer plain text over rich text for emails).

There are a few things you should know about this script.

• You need to configure it for you email client before it will run. You do this by opening the script and uncommenting the line indicating your email client.
• As written, it requires NetNewsWire 2.1.
• NetNewsWire will not run the script from its Script menu. I recommend using something like the system script menu or FastScripts
• html2text sometimes has refuses to translate pages. The two reasons I’ve seen for this are unencoded or unknown HTML entities. html2text can be updated to recognize the latter; I’m not sure what to do about the former.

You can visit the AppleScripts page for more information and to download the latest version

Update: Turns out Mail Headline supports 2.1, as well. Thanks for the info, Brent!

The more I think about it, the more I realize we have a great
real-world example that for all we talk about long tails and courting
the early adopters and the geek elite as a way to generate buzz and
figure out what the Next Big Thing is, we also need to be careful
about trusting the geeks TOO much, especially with consumer products.

Chuq’s post struck me as the flip side to my thoughts on MBAs and technology. Just like you can’t let the MBAs run amok designing products by feature checklists, you can’t let the geeks go crazy, either. To develop quality solutions, you need to focus on the user. This is something that both parties need to remember.

I was poking around the iTunes Store the other day and I stumbled across one of the tracks that should’ve been upgradable. Figuring that this wasn’t simply a processing issue, I decided to write iTunes Store Support and find out what was happening.

The short version is that the files I downloaded no longer corresponded to the files sold at the iTunes Store. According to the email I received from support, modifications to files on the iTunes Store can happen at any time and “be due to pricing, content issues or editing.”

In the same email, the support representative said that this shouldn’t make any difference from the customer perspective and offered me several alternatives for upgrading my tracks, provided I supplied the tracks and order numbers for the upgradable tracks.

I did this by hand and found 20 tracks. Afterwards, I remembered that there were hints for using Spotlight to figure out roughly how many upgradable tracks you should have based on the record label. Some searching led me to jescala.com, which had a script for counting the number of upgradable tracks. The page links to a text file of all the EMI record labels. A quick glance seems like it’s in agreement with Wikipedia’s EMI label page.

I modified the script slightly to remove the word count component and and point towards my the directory with my music files (in my case, ~/Music, but YMMV). Then I used the resulting list of record labels to find the corresponding tracks, using the mdfind command.

mdfind -onlyin ~/Music "kMDItemCopyright == *<label name>* kMDItemCodecs == '*protected*'"

Using Spotlight found an additional track that I’d missed.

There’s still a chance this won’t catch all of you upgradable music. I’ve found that not all tracks contain valid copyright data. Some tracks contain “℗ ” as the copyright string. Using this as the label name (removing the ‘*’s) should give you candidates for the iTunes Plus upgrade. I also suspect that some tracks may simple leave this field blank, but every time I search for a blank string, mds crashes.

The one downside of this approach is you loose the automatic copying of track information (play count, etc). You can fix this by getting the Legitimize Song AppleScript from Doug’s AppleScripts for iTunes. Ostensibly, this script exists to copy information from downloaded MP3s to purchased AAC files, but it can be modified for our purposes.

Open the AppleScript in Script Editor. If Script Editor asks you to find Internet Explorer, select Safari (yes, the script’s that old). Don’t worry about it, that section of the script is only a warning for people using pre-4.0 versions of iTunes. Look for the following line:

if the kind of firstTrack contains "AAC" then

Change “AAC” to “Purchased” and do the same on the following else if line. The script will now copy the information from the old Protected AAC file (m4p) to the new Purchased AAC file (m4a). For each updated file, select the old and new tracks and run the script. The information will be copied and the m4p file will be moved to the trash.

Long story short, if iTunes Plus isn’t identifying certain tracks as eligible for an upgrade, here’s the reason for it. iTunes support is aware of the issue and is willing to help (or, at least the rep I dealt with was willing to help). Hopefully, this information will come in handy for anybody who finds themselves in a similar position, either now or when additional labels make their tracks available in the newer format.