> Recent Entries
> Archive
> Friends
> User Info
> www.speirs.org

November 17th, 2004

12:07 am - Fair use rights, note taking and a defence of NSDrawer iTMS, iMovie and Final Cut Express I was playing with Final Cut Express tonight. It doesn't appear to support import of iTunes Music Store files like iMovie does. It does support AIFF import, so if you can get your iTMS track into AIFF, you can use it. One way to do that is to burn it to a CD and import to FCE from the CD. Another way is to send it through iMovie 4. Create a project in iMovie and add the track you want. Choose File -> Share, then select Expert Settings in the Quicktime tab. When asked for settings, choose "Sound to AIFF" and you'll get an AIFF file of your music track which you can import to FCE. There are other, possibly easier, possibly more legally dubious ways of doing this :-) That mythical note-taking brain-organising application I've been through so many applications, looking for that one place that I can stash all those stupid facts, notes and other random stuff. I tried OmniOutliner, but not everything is hierarchical. I tried VoodooPad, but I don't want to have to manage my categories manually. I tried DEVONThink, but it did a poor job of controlling the complexity. I tried MacJournal, but I needed more integration with Address Book and mail. I tried Circus Ponies Notebook, but it has a silly name and I hate applications that attempt real-world metaphors in their UI. I looked at Tinderbox, but I saw a price tag of $150 and a screenshot which had all the graphical pizzazz of, say, xfig. No, for $150, it has to at least look as good as OmniGraffle. balatro put me onto Chronos StickyBrain. I'm not ready to say that this is The One App just yet, but it looks promising. However, I do have the odd misgiving about the fact that it installs and runs an OpenBase daemon on your machine without telling you..... The one thing that no app seems to have cracked is the feature whereby I can drag an email from Mail.app and link that to a note as a "See Also" item. In defence of NSDrawer I read this blog post criticising NSDrawer, and I really don't agree with its conclusions, such as they are. I actually have come to quite like the Drawer element, when it's used correctly. I don't have sufficient passion to write this out in full, but I reject the common argument that Drawers inherently waste screen space. If you have a table which is the full height of any window, you can argue that the unpopulated part of the table "wastes space". Whether it's inside the bounds of the main window or outside it is, to my mind, rather irrelevant. I put together this one example of why I'm quite happy with Mail's use of a drawer rather than a table inside the window bounds. The reason is vertical space: ( screenshot ) And where I say "you would regain this space", that's more of a "maybe" because it's not a given that moving the drawer under the toolbar would mean that those buttons would be removed. There are some uses of a drawer which do waste screen space, but I think that Mail is one of the poorer examples to cite if you want to make that argument.

(Leave a comment)

(9 comments | Leave a comment)

(6 comments | Leave a comment)

11:45 pm - SubEthaEdit 2.1 Drama!!1 Whilst I think the people over at MacSlash are being more than a little melodramatic about the watermarking of the otherwise "free for non-commercial use" SubEthaEdit 2.1, I admit that it did make me pause and go "hmmmm". In the end, though, I don't really care that much about a watermark. SubEthaEdit 2.1 has added enough warm chewy goodness that I've re-pointed all my shell aliases at SEE rather than BBEdit. The rendezvous collaboration feature of SEE is just eye-popping, but I sometimes feel that that amazing and unique feature distracts from the fact that it's an extremely capable text editor in its own right. As bbum pointed out, SEE - by virtue of being NSTextView-based - gets emacs key bindings right, where BBEdit doesn't get them quite right. All the syntax colouring and language definitions are nicely text-based and hackable. Until BBEdit 8 came along, the only way to add syntax colouring to that app was to write a Carbon plugin. SubEthaEdit has block-editing (watch the movie). Best of all, it contains built-in completions for much (all?) of the Cocoa API. It's not quite as clever as Xcode's code sense, in that it won't insert a full message call with argument placeholders. (That would be a great feature, if anyone from the Coding Monkeys is reading here :-) Still, that's better than BBEdit, which has no meaningful symbol completion feature at all. I think there's an AppleScript with which you can simulate completion in BBEdit, but that's a kludge. Symbol completion was essentially my single criteria which determined whether or not I would pay for BBEdit 8. It's not there, so I didn't. I've been a paying BBEdit user since version 4.01 in 1996, but I'm ready for something new. In 1996 BBEdit was a general editor. Today, most of its innovation is going towards HTML editing while most of my work moves towards code editing. It's sad to drift apart from an old and faithful friend, but with 2.1, SubEthaEdit is serious competition to BBEdit. As a code editor, SEE has BBEdit beat hands down. As an HTML editor, I'd say BBEdit still rules the day. I wrote one "Hmmm" about the watermarking issue and I wrote four paragraphs about all the awesome stuff in SubEthaEdit 2.1. I can live with that ratio. I switched today, and you should too. Current Mood: impressed

(2 comments | Leave a comment)