Menu

Monthly Archives: March 2009

Last week my “@wii”:http://twitter.com/wii account on Twitter passed 3000 followers and seems to finally be growing strong after a year of neglect. I now try to post once every couple days with Nintendo news, and I’ll eventually throw in a tweet on new Wii Transfer updates. That was my evil plan from the beginning: have some fun with the account but also use it to build an audience and promote my own projects.

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”:http://wiitransfer.com/codes/. 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.

On a previous episode of “Core Intuition”:http://www.coreint.org/, number 14, Daniel and I talked about open source. One LGPL tool I use in Wii Transfer is called FFmpeg, a very popular video conversion project that forms the base of many video web sites, as well as the Mac QuickTime component, Perian.

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”:https://roundup.mplayerhq.hu/roundup/ffmpeg/issue582. Of course I am including the fix in a bug fix update to Wii Transfer (still “beta in the forums”:http://www.riverfold.com/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”:http://www.ffmpeg.org/shame.html.

It’s often true that the further away you get from an event, like the release day for the Safari 4 beta, the closer you get to a fair analysis. Initial Twitter reaction was gut level and some not even based on anything but screen shots. “My own post”:http://www.manton.org/2009/02/defending.html was admittedly slightly half baked, but I think it stands up fine.

Now we are seeing some more thoughtful analysis, including from “Dan Frakes of Macworld”:http://www.macworld.com/article/139026/2009/02/safari4tabs.html, and “Lukas Mathis”:http://ignorethecode.net/blog/2009/02/26/on-tabs-and-docking-and-title-bars/, and of course the thorough “John Gruber of Daring Fireball”:http://daringfireball.net/2009/03/safari_4_public_beta.

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.

“Brent Simmons is still looking”:http://inessential.com/2009/03/07/still_looking_for_a_version_control_syst for the perfect version control system:

“People talk about how wonderful are features like re-writing history — and I read that stuff and think, ‘Wow, Git’s really cool and powerful.’ But then I know it could suck me in and take away time from _real_ work. It’s _already_ more work — _for me_ — than when using Subversion.”

I haven’t used Git much since Daniel and I discussed it on an early “Core Intuition”:http://www.coreint.org/ episode. Like Brent I just don’t see a big win for single-person projects, although it’s fascinating to watch how open source projects are using “Github”:http://github.com/.

I like what Brent did a few months ago with his blog redesign, how both inessential.com and ranchero.com complement each other. He also wrote “more about his publishing system”:http://inessential.com/2009/01/30/new_publishing_system_tour_of_my_head, including a bit in passing about the tool I used to start my blog, Radio Userland.

I mention it because this blog is 7 years old today. Happy birthday to manton.org.