MiddleClickClose: New Home!

For those of you who have been pining for a working 64-bit version of MiddleClickClose, your patience is about to be rewarded. A fellow called Tom has taken the MCC code, gotten it working with 64-bit Safari and has moved it to its new home. I am no longer maintaining the code, since I don’t use Safari, so from now on, here’s where you should go for MCC:

github.com/Kabal/MiddleClickClose

There you will find all the source code so you can see how it works, or make changes yourself. If you are only interested in using it, you can get a binary bundle here. I haven’t tried it, but Tom assures me that it works. :-)

Thanks Tom-of-no-last-name for taking over the code.

MiddleClickClose Will Work With Snow Leopard But…

12/02/2009 Update: MiddleClickClose has been updated for 64-bit Safari. More info here.

I have upgraded my Mac to Snow Leopard, and as soon as I loaded Safari, I could see that MiddleClickClose was no longer working. I had already heard from someone that this was so, and I had expected it, so this was no surprise. It is possible to get it working again by right-clicking (or whatever the native OSX clicks are to get the context menu) on the Safari program in /Applications, selecting Get Info, and then checking the “Open in 32-bit mode” checkbox. Once you do that, SIMBL and MiddleClickClose both load, and the plugin works. But you’re in 32-bit mode.

MiddleClickClose is totally dependent on SIMBL. If SIMBL won’t load, neither will MiddleClickClose. The solution is, most likely, to get a 64-bit build of SIMBL, but I don’t know if that’s a simple matter or not. The SIMBL developer has said that he only has a PPC machine running Tiger, so I don’t really see how he’s going to get it running. If he does, then maybe there is hope. If not, your only option is to run Safari in 32-bit mode.

Or use Firefox, which is what I do.

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.

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.

Strange Firefox+Mac WordPress Admin Page

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?