mac

ExportToArchive *Does* Work With iPhoto ’09

/ joeygibson / 2 Comments

I just installed the iLife ’09 suite, which includes version 8.0 of iPhoto. While I haven’t had time to try out any of the new features, I did check to see if my ExportToArchive plugin still worked. I’m happy to report that it does still work. If you already had it installed, you don’t have to do anything; it will just work. If you don’t have it installed, the installer works with the latest version of iPhoto just fine.

If you encounter any problems using ExportToArchive with iPhoto ’09, please let me know.

Huzzah! MiddleClickClose Working In Safari 4!

/ joeygibson / 7 Comments

08/31/2009 Update: For Snow Leopard compatibility, see here.

08/13/2009 Update: It should now work with all future versions of Safari without having to update it again. Read about the change here.

06/09/2009 Update: Apple released the production version of Safari 4 yesterday at WWDC. I have just updated the plugin distribution, so if you download it now, it should work. If you already have it installed, follow the directions below for changing the version number to 5530.17 and your old installation should work. If you don’t yet have it installed, follow the directions here.

Thanks to Sylvain Frébourg, MiddleClickClose is now working with Safari 4. The fix is quite simple: change the MaxBundleVersion in the Info.plist file from what it was, to 5528.16. I know that I tried that, because I could see warnings about an incorrect version whilst watching Safari start up on the console. I must have changed something else at the same time and not realized it, because no matter what I set the version to, it wouldn’t load. Anyway, I reverted my SIMBL install and my SIMBL plugin directory from back in January using Time Machine, made the version number change, and now it works. It helps to be methodical, and I was not.

So, there are two ways you can go about getting it working for you. You can edit ~/Library/Application Support/SIMBL/Plugins/MiddleClickClose.bundle/Contents/Info.plist, changing 5525.13 to 5528.16 5530.17, or you can download a new zip file and re-install. Either way should work.

If only Apple would build this functionality into Safari itself…

No MiddleClickClose for Safari 4

/ joeygibson / 4 Comments

06/09/2009 Update: I thought I’d updated all the pages on my blog about MiddleClickClose, but I missed this one. It now works with Safari 4. Read about it here.

At least, not yet. I installed the Safari 4 beta this morning to check the compatibility of my MiddleClickClose extension. As someone else noted, it doesn’t work. I poked it a bit to see what I could see, but it’s still not loading. I don’t have time right now to try to figure it out, but I’ll try to take another whack at it this weekend.

Wanna know what I think of the beta, after about 15 minutes of playing with it? Of course you do. First, let’s analyze the list of what’s new. Right off the bat, I noticed these:

  • Top Sites: Opera did it a few years ago and called it Speed Dial
  • Tabs on Top: Chrome did it last year and did it much better
  • Cover Flow: Hey Apple, I think you’re overusing Cover Flow
  • Smart Address Field: Firefox and Chrome both have this
  • Smart Search Field: Firefox and Chrome both have this

I point these out because the press release from Apple about Safari 4, shown here at CruchGear, described these features as “innovative.” They are only innovative for the first browser to implement them, so I guess we have to give points to them for Cover Flow, but the others are just Apple playing catchup.

What’s still missing? Decent extension support, for one. Firefox has a rich set of extensions that do all sorts of cool things. I only use a few, but I wouldn’t want to browse without them. Technically it’s possible to write extensions for Safari, but it’s essentially an unsupported, filthy, dirty hack. While Firefox’s extension mechanism is a clusterf*ck of obscure files and object relationships, at least it’s documented and supported.

And of course Safari still doesn’t support closing of tabs with a middle-click. But I guess that goes back to Apple’s insane devotion to single-button mice.

Speaking of tabs, their implementation of “tabs on top” sucks compared to Chrome’s. With Chrome, there’s still about half a centimeter of title bar above the tabs for moving the window around and/or bringing it to the foreground. In Safari, the tabs go all the way to the top of the window, so if you have more than one tab open, you no longer have a title bar to grab. Yes, clicking-and-holding on a tab will let you move the window, but if you just wanted to bring the window to the foreground, if you clicked on a tab other than the one that was on top, you would end up bringing that tab to the front as you brought the window to the foreground, which isn’t what you wanted to do. But, truth be told, I don’t like tabs on top anyway. I was sort of interested when Chrome did it, but after using it for a while, I’d rather keep them where they’ve always been. (This article explains how to make Safari 4 move its tabs back below the address bar.)

As for Cover Flow, Apple is using it all over the place, and it’s getting old. I have no desire to see my bookmarks in Cover Flow mode. I know what my bookmarks are, thus I don’t need pictures to jog my memory.

Oh yeah, bookmarks. From what I can see, there is still no way to sort bookmarks. Yes, you can drag them into the order that you want, but that’s crap. I should be able to easily sort alphabetically by name, without resorting to manually dragging them into the order I want. Firefox does this with a right-click menu….

It’s not all bad, of course. From what Apple says, and from what I’ve heard, the JavaScript engine is blisteringly fast. I’ve always been impressed with Safari’s JavaScript speed, so improvements in this department are gravy. And for those who use Safari on Windows (I’ve never understood why anyone would, but who knows?), you finally have a Windows look & feel, so it doesn’t look like a Mac app running on Windows. That’s as it should be; I don’t like L&F pollution.

This is a beta release, so some of these things could change. I would really like to see official support for middle-click closing of tabs and bookmark sorting but I’m not going to hold my breath.

Objective-C 2.0 Properties Are Needlessly Verbose

/ joeygibson / 3 Comments

I’ve been working in Objective-C for a little while now; not quite two years, off and on. I was really excited when Apple announced that Objective-C 2.0 was going to have generated properties, but the syntax they gave us leaves me flat, as it is needlessly verbose.

For those who don’t know, in Objective-C 1.x, if you had an instance variable in a class that you wanted to expose, you had to provide getter and setter methods for it, just like you do in Java, C++ and several other OO languages. You would see something like this in MyClass.h:

@interface MyClass : NSObject {
    NSString *name;
}

- (void) setName: (NSString *) aName;
- (NSString *) name;
@end

and then in MyClass.m, you would see this:

#import "MyClass.h"

@implementation MyClass
- (void) setName: (NSString *) aName
{
    [aName retain];
    [name release];
    name = aName;
}

- (NSString *) name
{
    return name;
}
@end

Objective-C 2.0 promised to eliminate all that boilerplate code in your *.m files for getting and setting variables. But they did it in a strange way. Now, in MyClass.h, you would see this:

@interface MyClass : NSObject {
    NSString *name;
}

@property(nonatomic, retain) NSString *name;
@end

and then in MyClass.m, this

#import "MyClass.h"

@implementation MyClass

@synthesize name

@end

Now, it certainly cut out quite a bit of code for the getter and setter, but why do I have to declare the type of the property twice? You have to declare the instance variable as usual, but then you also have to specify the data type again when you add the @property declaration. There’s no reason I can think of that those two lines couldn’t have been combined into the variable declaration. Objective-C already has tokens that are ignored, such as IBOutlet, so it shouldn’t have been an issue with breaking the parser. And the @synthesize declaration in the *.m file is annoying, but I guess it was necessary to keep the properties from being auto-created in the wrong place.  In my opinion, this is what property declarations should look like

@interface MyClass : NSObject {
    @property(nonatomic, retain) NSString *name;
}

@end

That’s it. No duplication. Simple. Elegant.

Can anyone think of a good reason why they didn’t do it like that?

12/28/2008 15:13:23 Update: As Ahruman pointed out in his comment, I misspoke about IBOutlet. It is not actually ignored, but is used to tag an instance variable for use by Interface Builder. Sorry for the confusion. And be sure to read his comment below. It’s packed with good info that I didn’t know.

Problems With Latest Version of iTerm

/ joeygibson / 1 Comment

I love iTerm as a replacement for Terminal.app, but this morning after letting iTerm upgrade itself to “Build 0.9.5.0909”, all my settings, profiles and bookmarks were lost. I don’t know why, but that’s what happened. I pulled back the iTerm.plist from ~/Library/Preferences using Time Machine, but that didn’t seem to fix it. I also tried to restore iTerm.app using Time Machine, but there was something funky going on with TM, so I wasn’t able to.

In the end I just reset the preferences as best I could from memory and started recreating my bookmarks. You might want to wait to upgrade.

Chrome Is Cool, But No Mac Version Yet

/ joeygibson / 2 Comments

Yesterday, the internets were all a-flutter about Chrome, Google’s new surprise web browser. Sure, I downloaded it, like everyone else, and I was impressed by its rendering speed. I used it for a few hours without any problems at all. It works with every site I tried it with, and speedily. I’m especially juiced about the JavaScript JIT engine called V8, and the fact that each tab is its own process, separate from other tabs.

But here’s the rub: for now, it’s Windows-only. How can this be? It’s built on top of WebKit, which is Apple’s updated version of KHTML, and both run on OSX and Linux. So what gives, Google? I know they say that there will be OSX and Linux versions “soon,” but how long is that?

I found directions for building Chromium, which says on its homepage, “Google Chrome is built with open source code from Chromium.” So I downloaded all the source code and tried to build it. Here’s 2,000 words about how it went

I guess I’ll just have to wait for the official OSX release.

Strange Firefox+Mac WordPress Admin Page

/ joeygibson

Below is a screencap of what part of my WordPress 2.6.1 admin page looks like when I view it using Firefox 3.0.1 on Leopard.

If you click on it to view it better, you’ll see the problem. The stats graph is shifted about 200 pixels to the right and about 150 pixels down. On Safari it looks perfect, but not on Firefox. This doesn’t happen with Firefox on Windows, so it’s some sort of quirk with the Mac version.

Has anyone else seen this, and do you have any suggestions?

Apple Still Working on MobileMe

/ joeygibson

I just received an email from Apple regarding MobileMe. Here’s what it said

We have already made many improvements to MobileMe, but we still have many more to make. To recognize our users’ patience, we are giving every MobileMe subscriber as of today a free 60 day extension. This is in addition to the one month extension most subscribers have already received. We are working very hard to make MobileMe a great service we can all be proud of. We know that MobileMe’s launch has not been our finest hour, and we truly appreciate your patience as we turn this around.

It’s good to see the bit in there about this launch not being their “finest hour.” That shows that they recognize how bad this rollout has been. But they better solve it soon or they’ll be giving everyone a free year. We’re already up to 90 days of free service.

I really like MobileMe, though the only part of it that I really use is syncing bookmarks and stuff between my Mac Pro and iBook. I tried to setup the Outlook integration on my Windows laptop the other day, but it didn’t seem to actually do anything. I guess that’s part of what’s broken with the service, maybe.

Strange Seg Fault In Simple Cocoa App

/ joeygibson / 1 Comment

I just got Aaron Hillegass’ 3rd edition of Cocoa(R) Programming for Mac(R) OS X (3rd Edition) and am working through it as if I never went through the 2nd edition. (It’s been so long since I did any Cocoa, that seemed like the smart thing to do.) Anyway, I’m in Chapter 4 on memory management and things were going fine. Until all of a sudden, the program started dying with a segmentation fault. After trying to figure out what I’d done wrong, I figured I’d mistyped something and just wasn’t seeing it, so I reverted my changes back to what I had in my Subversion repo. I then started making the changes again. And again the program died with a segfault. 

Any time I’m working through a programming book, I always type all the examples in by hand, rather than downloading pre-written code. I learn better that way. But in cases like this, I don’t have a problem with looking at the author-provided code to see where I went wrong. I downloaded the solutions from Aaron’s site and started comparing. I found the problem pretty quickly.

Originally, the code for creating the NSCalendarDate object for today’s date was

NSCalendarDate *now = [[NSCalendarDate alloc] init];

which, when you later add the code to release it, would have worked fine. But at some point between when I wrote that line of code and when I added the release, Aaron mentioned a convenience method on NSCalendarDate for getting back an autoreleased date object. That code looks like this

NSCalendarDate *now = [NSCalendarDate calendarDate];

I had changed my code to use that instead of the original version. That was in Chapter 3. So, when I hit Chapter 4 and added the call to release the date object, I ended up with my segfault. The chapter assumed that you still had the alloc & init calls, and so made no mention of the calamity that would ensue if you had switched to the other way of getting today’s date.

What made this difficult to find was when the segfault occurred. It didn’t happen when I called release on the date object. It happened on this line

[pool drain];

which is one line before the program ends. That’s boilerplate code there, so it was really strange that it was barfing. The reason this caused the problem is that this way of getting a date is autoreleased, which means that unless I retain it somewhere, it’s going to get deallocated when the NSAutoReleasePool is deallocated. But when I called release on it, I ended up setting it’s retain count to 0, so when the pool was drained, it ended up sending a release message to an object that had already been deallocated, which is a no-no.

Bottom line is that had this been a big program, this could have been really hard to track down. Of course, turning on the Objective-C 2.0 garbage collector would have solved the problem too, but then you have a Leopard-only program.

I Paid My $99 To Apple

/ joeygibson / 5 Comments

As I said yesterday, I finally got my acceptance letter from Apple that essentially allows me to pay them $99 in order to develop iPhone software. I have just now paid the $99, so now it’s just a matter of waiting for the license or whatever it is that they will send out. Let’s hope it doesn’t take as long as it did for the acceptance letter.

As I write this, I am downloading the iPhone SDK. I played around with the first beta Apple released, but I haven’t really done anything with it since then. That was before they got Interface Builder going, so it should be a lot better now than it was then. I’m looking forward to getting started; now I just need to think of something that needs writing.

07/13/2008 00:37 Update: About 20 minutes after posting this, my Activation Code email arrived from Apple. Fun times ahead.