Ryan Irelan asked me the other day if Clipstart would support a simple email option, for quickly sharing a video with family without uploading to a web site. This is a pretty good candidate for using Clipstart's file actions, which allow you to process the selected video files with a script.

I liked how Acorn handled this kind of thing, so I essentially lifted its file actions feature directly and put it into Clipstart, even down to the ACShortcutKey shortcut comments. Even though Acorn is for still images and Clipstart for videos, it seemed similar enough that you could conceivably take lightly-modified scripts from one app and use it the other, if they did not deal with the file's contents.

Here's the email script that will be included in Clipstart 1.1.1:

#!/usr/bin/osascript

    tell application "Mail"
        set new_msg to make new outgoing message with properties {subject:filename, content:"" & return & return}

        tell new_msg
            set visible to true
            tell content
                make new attachment with properties {file name:filepath} at after the last paragraph
            end tell
        end tell

        activate
    end tell
end

Running scripts has been in Clipstart since 1.0. The implementation is pretty simple. I parse the available file action files to extract the executable path and any shortcut keys and modifiers, then dynamically create the menu items. When it's time to run an action I use NSTask and friends to execute the program and pass the script file and selected movie path to it.

Instead of this:

/path/to/myscript.sh /path/to/movie.avi

Clipstart does it like one of these:

/usr/bin/bash /path/to/myscript.sh /path/to/movie.avi
/usr/bin/osascript /path/to/myscript.sh /path/to/movie.avi

I did this to not require setting +x on the file, but it also seems to be a more convenient way of processing command line arguments when run from osascript.

Even before the keynote was over I was getting questions — which continued all week — about whether I had iPhone plans. At the very least, Clipstart 1.1 needs to be able to import videos off of the 3GS. That's in beta now. But what about a native phone app?

I've convinced myself over the last couple weeks, after listening to what people are doing with their phones and evaluating the existing applications in the App Store, that Clipstart for iPhone would be a very useful app. Video on the 3GS is a big deal. Eventually I can see a new top-level Video category in the App Store, and whoever is in that list is going to do very well.

Neven Mrgan sums up the urgency:

"I'm sure Phil Schiller's prediction of iPhone 3GS quickly becoming the most popular video-capable phone — if not the most popular consumer video device period — is right on the money. A message for those working on apps that help us shoot, edit, organize, and share quick, casual video clips: get ready to get busy."

I'll admit that after WWDC I panicked, thinking for a moment that I had to deliver Clipstart for iPhone immediately, and drop everything I'm doing to make that happen. I no longer believe that. The Mac version of Clipstart has a lot of potential and I can't get too distracted from following up on that. But at the same time I will be expanding what I do on the phone, so we'll see where that goes.

"I have been thinking for some time of eliminating FastScripts Lite. Customers found it confusing to differentiate between the versions, and I found it tedious to artificially maintain two versions. With the new, liberal evaluation terms in FastScripts 2.4, all of the old Lite functionality and much more is now included for free in the full version.

It's always a risk to make a pricing or demo limit change. Whether accurate or not, I imagine the financial side of product development as a delicate tower of blocks, where the slightest change could cause your whole sales structure to come crashing down. For that reason I tend to not touch anything if it is working, but I recognize that I am probably holding my business back at the same time by not being more flexible.

"I'm delighted to be able to plant a flag and say that in 2010, Rogue Amoeba will again be exhibiting at Macworld. We still believe in Macworld and all that it provides. We believe it's relevant, useful, and worth having. We believe that meeting new customers, talking to existing ones, and sharing a great time with all manner of Mac friends, is still worth doing."

I like companies that make decisions based not just on spreadsheet numbers, but on belief and instinct too. It's a shame Apple didn't show more of that when weighing whether to continue exhibiting at Macworld. Because Rogue Amoeba doesn't sell on the show floor, the conference has to be less about directly recouping costs and more about connecting with customers and building goodwill and name recognition. See also Should I Exhibit At Macworld, from Paul Kafasis in 2007.

I haven't attended or exhibited at a Macworld since the late 90s, and every year I miss it.

I was falling into that infinite 1.0 cycle where I could continue to improve the application forever without releasing it. The sooner I noticed that trap, the sooner I was able to correct course and get the app into the hands of real users.

The app is called Clipstart. It's for importing, tagging, and uploading home movies. I have high hopes for the app and a lot of fun stuff planned for the future.

As usual, a lot of people talked about the product even before I did. My thanks to Dan Moren of Macworld for covering the launch before I even had a chance to spam him with a press release; to John Gruber for posting about how he uses it; and to Duncan Davidson and Mike Zornek for their write-ups. I also very much appreciate all the retweets and goodwill from my friends on Twitter. Those meant a lot.

But when listening to the Macworld podcast a week ago (the episode with Dan Moren and Jason Snell back from the iPhone 3.0 announcement) it struck me that iPhone software is a little unique. They made the point, which I think is true for most software, that Apple's offering is usually simple, full of holes that could be filled with new features from third-party developers. There is usually room for a developer with a unique twist on an idea to market and sell his solution to like-minded users, even if Apple ships a default good-enough app for most people.

Except there's one pretty significant problem, especially on the iPhone. Apple cheats.

Third-party apps cannot run in the background. So it doesn't matter how many features a recording app has that Apple won't bother to implement, background recording is the killer feature that will always remain out of reach for developers.

Put another way, if the Apple app didn't record in the background and a third-party app could, that third-party app would likely be worth $5-10 to many people for that one feature alone. But give Apple background recording and it doesn't matter how many features another app adds — syncing music, FTPing to a server, multiple tracks, sound effects, more file formats — it's going to be a challenge to convince users they need two recording apps. I expect some audio developers to overcompensate by adding every feature listed above and more to make up for the one feature they can't have.

This is the new MacHeist promise, right? Not just exposure, although that's part of it, but selling so many tens of thousands of copies that the developers do very well regardless of their tiny underpriced cut of the profits per sale.

We don't get hail in Austin very often. I took the Flip out and filmed a little bit of it, as golf-ball sized balls of ice blanketed the yard. Afterwards every roofing company in Texas descended on Austin offering steep discounts, in some cases even covering an insurance deductable of $2000 or more. Depending on who you ask, such practices may or may not be considered insurance fraud, but like MacHeist it does come with ethical considerations. The roofing companies knew that they could do so much business in the next 2 weeks that they will easily make up for reduced profits by the sheer volume of work.

There's another kind of discount shared between roofing companies and MacHeist. Users promote the package they just purchased in exchange for further discounts. For MacHeist it's spamming your Twitter followers (I get a free Delicious Library!). For roofers it's spamming your neighbors with a yard sign (I get $250 off!).

I've learned a few things from all of this that I think will help me make my own indie business stronger, or at least more consistent. I gladly give free licenses to reviewers, bloggers, and small Mac user groups. I also routinely do 10-20% off discounts that anyone who knows how to search Twitter or RetailMeNot.com can use.

But I'm just going to have a default "no thanks" answer for big promotions and mass giveaways. It's consistent with what I believe about keeping prices fair to sustain a Mac business, and it takes the guess work out of which promotions harm the Mac ecosystem and which are a great deal for everyone.

I view @wii as a gift. I don't know how long it will be under my control. As Twitter continues to go mainstream, eventually I expect Nintendo will want my little 3-character Twitter name for themselves, and I might just be glad to hand it off. Twitter works best with a personal voice, and I've already all but closed some of my secondary accounts.

I'm more conflicted about what to do with the Wii Friend Codes site. At one time I imagined it as a full Riverfold product, with integrated Mac and iPhone apps, but now I find that I lack the passion to really take it to new places. And to be honest, it works as is.

In the latest Wii Transfer I updated to a new version of FFmpeg, which it turns out had a major bug: broken audio for 8-bit input sources. Of course I am including the fix in a bug fix update to Wii Transfer (still beta in the forums), but not before many customers were hit by the problem.

Not to look a gift horse in the mouth, but it reminds me of one annoyance with FFmpeg: no releases. You basically just follow trunk, and if there's a bug, sorry. This is understandable. It's open source, after all, and the developers don't owe you anything. But at the same time, it's one of the reasons I've moved to Perian-only in my new app, and left the FFmpeg trunk and other similar open source command line tool projects behind. With Perian I can track specific major releases and know that someone has tested them. QTKit is good enough now on Leopard that I feel comfortable basing on app on it.

Daniel also mentioned in passing that violators of open source licenses are likely to get away with it. I think that's largely true, but I found that the FFmpeg developer base has a pretty keen eye to this issue. If they notice that commercial software is using FFmpeg or MEncoder or other portions inappropriately, they will list the software in their hall of shame.

Now we are seeing some more thoughtful analysis, including from Dan Frakes of Macworld, and Lukas Mathis, and of course the thorough John Gruber of Daring Fireball.

I wanted to revisit one thing with click-through. If you eliminate the mouse rollovers and click-through for inactive tabs, you end up with surprisingly few places to accidentally click. Here are two screenshots illustrating the difference between Safari 4 and BBEdit.

It's true that the file icon needs a hold-and-drag, so it's harder to click, and the hide toolbar button is off to the side and less dangerous than closing a tab. Nevertheless, viewed by pixels alone there isn't a significant difference between the safely clickable area of these two window title bars if Apple makes this small change.

Update: If I left too much to the imagination, here are examples of the real Safari 4 clickable areas, not the way I wish it would be above.

And the extreme example with even more tabs:

The important point is that if you disable click-through for inactive tabs, the safe area does not change even with dozens of tabs, and in my opinion it is only marginally worse than other standard Mac applications, as shown in the first two screenshots. The current Safari 4 behavior, on the other hand, continues to degrade until the window title bar is nearly useless.