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?
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
~/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
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
into the workspace selection dialog, rather than creating them in
as you might expect, the workspace is actually created in
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
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:
- The application bundle (i.e. inside the
(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
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,
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.