MiddleClickClose Updated For Future Safari Versions

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

Yesterday Apple release Safari 4.0.3 which, of course, broke MiddleClickClose. Again. The problem lies in the file Info.plist that is part of the plugin. From what I read about SIMBL, good practices said that you should include a key called MaxBundleVersion whose value was the internal version number of the app you were patching. The problem is that every time Safari gets updated, Apple increments that number and SIMBL won’t load the extension any more, since it proclaims that the maximum version of Safari it should be loaded with is the previous version.

I usually play catch-up with Apple and get MiddleClickClose updated a day or two after a new Safari ships. I’ve decided to stop that and have removed the MaxBundleVersion from the Info.plist. This is, after all, a dirty hack, so why not make it even hackier?

If you re-download and re-install, you shouldn’t ever need to update it again. If you already have it installed, you can just edit the Info.plist file that will be in ~/Library/Application Support/SIMBL/Plugins/MiddleClickClose.bundle/Contents, removing the two lines that look like this

<key>MaxBundleVersion</key>
<string>5530.18</string>

Here are the new downloads

MiddleClickClose for Safari 4.0.1

A day or so ago Apple released Safari 4.0.1 and bumped the version number in the process. Safari 4.0 was 5530.17, while Safari 4.0.1 is 5530.18. After installing the update, MiddleClickClose was still loading, even with the minor version mismatch. I don’t know if Safari only looks at the first part of the number when specified in an Info.plist for MaxBundleVersion, but just to be on the safe side, I bumped it to 5530.18 and have re-released it. If it’s working fine for you, don’t bother getting this version. That’s the only change I made.

ExportToArchive *Does* Work With iPhoto ’09

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!

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

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

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.

OH NOES! I’ve Lost My .emacs File!

I was first exposed to Emacs back in 1991. It took me a while to warm up to it, but I did and I have been using it ever since. Once I started using it on a regular basis, I started customizing it. You can write modules and such for it, but for simple customizations, you can just put them in a hidden file called .emacs in your home directory. As time passed, I would add various changes to my .emacs file, adding convenience functions in Lisp and other bits to make me more productive. As I changed jobs and changed computers, I always made a point of taking this file with me so I’d always have it.

When I switched from Windows to OSX in November of 2006, I didn’t immediately need Emacs, so I didn’t think to copy my .emacs file over. And once I didn’t need the Windows machine any more, I put Linux on it and turned it into a server. But guess what I forgot to do. Yep, I forgot to copy my .emacs someplace safe. I hadn’t noticed it was missing until today. I need to run Emacs for something and when I went to make a change to my .emacs file, that’s when I realized it was missing. I checked my backup drive, which has a bunch of stuff off that old PC, but my .emacs file was nowhere to be found.

Even though I haven’t used Emacs in a while, I need to now, and having that file sure would be nice. But even if I didn’t need to use Emacs right now, I’m still a bit sad to see the file go, since I carted it around for so long. Keeping one file with you for 15 years is quite a long time, wouldn’t you agree?

Dear Apple: Some Java Love, Please?

I love your machines. Truly, I do. Back in 1988 I bought a toaster-model Mac SE, with one megabyte of RAM, and I loved it. It only had a nine inch, black-and-white screen, and I loved it. For various reasons, I sort of lost the love for a while, until 2006. I acquired an iBook G4 in a hardware trade with a friend and I quickly became hooked on the sweet goodness that is OSX. That was in August, 2006. Two months later I bought a Mac Pro, which I love so much I sometimes feel the need to kiss it goodnight.

But there’s one thing about the Mac that bothers me: lousy Java support. Sun handles JDK releases for Windows and Sun machines and every Linux system on the planet. Yet, for some inscrutable reason, you have decided to handle Java for OSX yourself. And, not to be rude, but I just have to say that you suck at maintaining Java for the Mac!!! Let me ‘splain.

Sun released the first version of Java 6 for Windows, Linux and Solaris in December 2006. Two days ago, Sun released the tenth update for Java 6, again for Windows, Linux and Solaris. On September 24, 2008, you guys released Java 6_07, which was nice to finally get it, but it’s only for Leopard systems and it’s only for 64bit machines. My Mac Pro is 64bit and Leopard, but my iBook is 32bit and can’t run Leopard. And what about the tons of other developers out there who don’t meet these requirements? I can’t think of a good reason you have restricted Java 6 in this way, but I can think of a few bad reasons. Probably the easiest to come up with is that you’re trying to force Java developers to buy more expensive Apple machines.

What’s really funny about the crappy state of Java on the Mac is comments from Sir Steve himself, several years ago. I was at JavaOne in 2000. Sir Steve was the Mystery Date™ for the keynote speech on Day One of the conference. His Steveness trots on stage, clad all in black, and proclaims that he was going to make the Mac the ultimate platform for Java developers. Apple would be bundling Java 2 SE with OSX. And the crowd went wild. And he did make the Mac a great Java development platform. For a while. I can’t tell you how many conferences I went to after that, Java conferences, where the majority of developers were toting Mac laptops around. 

But then you started falling behind with the releases. And then you started restricting which of your users were worthy of getting updates. What gives, Apple? If Sun can release timely versions of Java that run on a ton of disparate systems, why can’t you release timely versions that run across your own hardware family? It’s absurd that you are only supporting 64bit Leopard system for the latest versions of Java, and even then you make us wait forever. 

So, how can we fix this? I think you should go back to Sun and say something like,

I’m sorry, Sun. We like to meticulously control everything, but in this case, that desire has caused us to hose down our customers. They’re not happy, and we can’t figure out a good way to appease them. Please, Sun, would you take over maintenance of the JDK/JRE for OSX? We’d really appreciate it.

Or something like that. Something needs to happen soon. Although the lastest version sounds like just another update to Java6, there are actually lots of new features that are going to really improve Java. Except those of us on the Mac have to wait for some unknown amount of time before you guys release your own version. And if we’re not 64bit Leopard, we’re screwed.

Please, Apple, help us out with some timely Java love, OK?

Sincerely,

Joey Gibson

Problems With Latest Version of iTerm

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

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.