Tonight’s MacRuby/Xcode lesson: An object (say, an instance of a subclass of
NSArrayController) created in Interface Builder won’t necessarily have its
initialize method called when the program runs. This, I guess, is because the object was instantiated when you created it in Interface Builder, and cryogenically frozen, and when your program runs, it doesn’t instantiate the object, it merely wakes it up. So you should put the initialization code in
awakeFromNib. I think.
init method on an instance of a subclass of
NSObject was called. I don’t know why
init and not
initialize. I’ve got a lot to learn.)
I wrote something with MacRuby, finally. It’s a tool to help me post music every day over on my non-technical blog. The MacRuby part is that it uses iTunes to convert uncompressed audio to MP3, add metadata, and post it to my web site. And add it to my library along the way. That’s pretty cool. The script also uploads the track to my web site, but that’s straight Ruby.
In retrospect I think iTunes is not the right tool for this job. It’s a hammer, not a scalpel. It doesn’t give you a lot of fine control, and it takes more energy than the task really warrants. For example, sometimes I need to find a specific track in the library. The API iTunes offers through Scripting Bridge doesn’t let me look up a track by multiple criteria (track 28 from the album “Music Every Day” in MP3 format) – it just gives me the same keyword search you find in the UI. So I can search for the album “Music Every Day” and then loop through the returned tracks looking for the one I need. It gets the job done, but it’s not ideal.
So if I were starting over I might use LAME and RubyMp3info, or something. But it was interesting to get some practice with MacRuby, and if I ever decided to put a GUI on this it’ll be good to have had the experience. The code is on GitHub, if you’re curious.
Here’s a simpler version of that last post using Rich Kilmer’s HotCocoa library. I also use the approach I suggested at the end of the last post: Build a menu each time it’s requested, instead of trying to keep one at the ready.
I’ve been wanting to write a Mac application since I got this computer a year or so ago. Still haven’t, but today I ran through a MacRuby/Cocoa tutorial, and I’m hoping to find the time to code the app I have in mind soon, before I forget whatever I just learned. More about that if it happens.
My original plan was to make the app accessible from the global menu bar, but then I learned that Apple’s Human Interface Guidelines discourage it, and you know how I love guidelines. And humans. So instead I’m going to use a Dock menu. The main advantage of both, for my purposes, is that after you take some action, control returns immediately to whatever application you were using; perfect for programs you use for a moment now and then, but don’t really spend time in.
Anyway, I thought I’d share what I learned about implementing Dock menus in MacRuby. (more…)