Alex headshot

AlBlue’s Blog

Macs, Modularity and More

Mac doesn't get much love

2010, eclipse, mac

Recently, Doug posted that Mac Gets No Love on the Eclipse platform – and rather than replying as a comment, it makes sense to follow up with a separate posting.

I first got into helping Eclipse back in 2002 when the first port of the Mac application was being readied for Eclipse 2.1 on Mac. (I mentioned at the time that using Cocoa rather than Carbon was the way forward; it took another five or so years for that advice to be heeded :-) Although I’d been using Eclipse since the 1.0 days (having worked for IBM on Visual Age for Java, and subsequently its evolution into Studio), it was the migration to Mac that brought me into the Eclipse community as opposed to a silent user. However, I’d been using Macs since the OSX transition, and before that, Nextstep; so I wanted to bring that to the table. (This was in the days before OSX was trendy; by comparison, the first iPod had launched a year before.)

Before going on largely to agree with Doug, I do want to call out specific mention to the SWT folks who have ported their widget set to Mac (twice, now) and without whom we wouldn’t have an Eclipse platform at all. Many notable people have worked on the Mac port, including the current Scott Kovatch (first at Apple, then at Adobe, now at IBM), but also past luminaries such as Kevin Barnes and Andre Weinand who did a lot of the original porting. There are specific things which make an Eclipse app feel more Mac-like, including putting Preferences under the application menu, but most of these are SWT team fixes.

However, the problem is that outside of the SWT team, there is virtually no Mac knowledge, or until recently, user base. No-where is this more visible than the release engineering and build projects; what we have out of the box is a project laid out specifically for Windows users. And until you’ve used Macs for a while, it’s not even clear that there is a problem; after all, if it works in Windows, it must be OK for everyone else, right?

Over four years ago, I blogged about 10 things I hate about Eclipse, including the fact that it’s not a proper Mac layout.

Much like Unix has configuration in /etc and system binaries in /bin, Mac applications have a specific layout as well. Furthermore, there’s even an eclipse executable at the top level because the releng build fails if there isn’t a file there with that name; despite this not being used by the Eclipse.app itself (it has the copy tucked safely inside it). It also means that you can’t drag-and-drop a Mac install into any ~/Applications directory, because the features and plugins directories are in the wrong place. I even started Maclipse as a way of better wrapping up the Mac platform (DMG, files in the right place, drag-and-drop install) to try and show how these problems could be addressed – but there was no interest in making it happen at Eclipse. I seem to recall the conversation trying to get it to work was “it works this way on all other platforms; we’re not doing anything different for the Mac” though that was in the days when Macs hadn’t got the popularity surge that they have today.

There’s also a lot of issues caused by decisions of downstream teams which may look OK on their platform, but not on Macs. Mylyn’s use of CCombo boxes, for example, makes the UI on a Mac look ugly when the CCombo offers no functionality that the Combo does on the Mac platform. Heck, it’s even been fingered as a memory leak and yet nothing is still done about it. Here’s what it looks like on Windows versus Mac OSX:

Then there’s little things, like the warning message shown in JDT’s “sort members” dialog. Because it uses Label.setEnabled(false) rather than Label.setVisible(false), the text is completely missing on the dialog but with a giant blank space on Eclipse 3.4. (I not only provided the code fix for that but also argued that using the enabled state wasn’t right for all platforms; or even that the Mac platform should have a special-case. But that was overruled by a non-Mac user.) Since then, the Eclipse 3.5 SWT on Cocoa now ignores the Label.setEnabled() call, which is why it now shows up on Eclipse 3.5 onwards. (The issue may still be present on the Carbon builds.) Here’s what it looks like on Windows and Mac OSX:

Another example: when creating an Eclipse workspace, if you put ~/Projects into the workspace selection dialog, rather than creating them in ~/Projects as you might expect, the workspace is actually created in /Users/alex/Applications/Eclipse-3.6M5/Eclipse.app/Contents/MacOS/~/foo. The use of ~ to denote the user’s home directory (and it’s available under user.home) is a widely used Unix extension; so the fact that it’s not supported is a minor annoyance. And yes, I raised a bug ages ago.

Finally, many Mac applications have the ability to install additional plugins by dragging-and-dropping them into an appropriate folder; typically ~/Library/Application Support/Eclipse/PlugIns. In fact, Mac applications generally have three levels of location to search for installing such items:

  • A ~/Library/Application Support/* directory
  • A /Library/Application Support/* directory
  • The application bundle (i.e. inside the .app itself)

(Technically there’s a fourth; /Network/Library/Application Support/*, but this is rarely searched on application launch due to potential delays with the network; and in fact, these days, is rarely used at all.)

Wouldn’t it be nice if one could create an Eclipse (or OSGi) runtime which would allow a user to install components by dragging-and-dropping the bundles into the right directory? After all, this works for the majority of other applications (see Doug’s scripts for iTunes for a lot that work with iTunes; you can also extend Mail.app with Hawk Wings plugins; even Contacts can launch Google Maps).

However, this will never happen. P2, the bane of many, has a dropins directory which is almost exactly right for this job – except that it’s a singleton. You can’t have more than one dropins directory. (Well, OK, you can have two; a dropins directory somewhere else, and the one that’s in the eclipse folder.) This enhancement has been categorically ruled out from ever appearing in Eclipse P2:

Installing by just adding a folder was just plain wrong and resulted in many problems in UM at the time because ppl would break themselves and then complain. I’m against reintroducing something like that and so are the other p2 committers, which is why I closed the original bug as WONTFIX. p2 provides bundle pooling which provide a much better way to do this.

… except this has nothing to do with bundle pooling. It’s about making life easy for those that want to drag-and-drop install. Which is pretty weird, because the dropins folder already allows you to drop and install in one place; so why not several? Sadly, this kind of attitude is prevalent when it comes to improvements to the Eclipse platform for Mac. But hey, building a decent Mac app bundle keeps getting raised periodically.

So, I think it’s important to praise the work done by the SWT team, and in particular, the improvements with the Cocoa build; but there’s a lot of difference between “uses native widgets” and “is a proper Mac application”. The SWT team is doing great work on the former; but the latter requires greater understanding from the way that projects use those components.