Eclipse/OS X Rant
I recently had a little freakout in response to a blog entry by Wassim Melhem regarding Eclipse on the Mac. At the time I was getting strange behavior with 3.2.0 on my Macbook Pro. Eclipse would crash while running a PDE build, runtime workbenches would suddenly disappear, and several other one-time inconsistencies popped up. Since then I started with a fresh 3.2.1 install and have had no issues. Regardless, there are some things about Eclipse on the Mac that still bug me, but first, a few disclaimers:
Disclaimer #1
- I’m a big fan of Eclipse. I am a committer. I know of many people that work really hard on Eclipse to make it the best IDE it can be. This post is an attempt on my part to describe exactly what troubles me about Eclipse on OS X, not to piss people off.
Disclaimer #2 -
These issues may have nothing to do with Eclipse at all. Maybe it’s Carbon, maybe it’s OS X, or maybe it’s Apple’s Java. Heck, it could be cosmic rays! All I know is that Eclipse is the only app I use that feels better on Linux and Windows than on my Mac.
Disclaimer #3
- I’m crazy, I talk to myself, and am a hazard to those around me.
Ok, enough of these stupid disclaimers. On to the rant:
1. Toolbar icons are too hard to click. It seems on the Mac that the clickable region of a image button is the non-transparent region. On Linux it’s the whole button, and I’m pretty sure it’s the same in Windows. So this means my brain has to work that much harder to get to one of those little buttons (because each button has a different image).
| 2. Fonts are too big in the tree views. Windows and Linux seem to be more concise and at the same time, just as easy to read. I’ve played around with other fonts but I can’t seem to find anything that works well. Also, the arrows used to expand and collapse nodes are too hard to click. It seems the arrows suffer the same problem the toolbar icons have. |
|
5. Weird delays. Saving a file sometimes takes 10 seconds. Opening an editor sometimes takes 20. The resource monitor doesn’t seem to show any extra load, but Eclipse seems to space-out once or twice a day. I have 2 Gb of RAM and Eclipse rolls with 512Mb.
6. Speed. Starting a runtime workbench on comparable hardware is noticeably slower on a Mac. It just is. I’m serious. I’ve claimed this to people in the past and they blatanly told me I was mistaken. Can someone make it go faster?
7. Overlapping text editor line decorations. By default you can have a breakpoint set on a line with a warning and not see the breakpoint. Those little breakpoints love to hide!
| 8. Window painting inconsistencies. Like a Sasquatch, window refresh problems can jump out of the bushes just long enough to scare you only to disappear before you can get the lens cap off. Luckily I’ve captured one on film. See the white horizontal line to the left? No? Look really hard. And, no, I didn’t Photoshop this. | 
|
| 9. Truncated Menus. I like to scroll as much as the next guy. But seriously, these menus don’t need to be truncated. I shouldn’t have to scroll down manually just because I open a context menu close to the border of my screen. | 
|
I imagine most if not all of these issues can be classified as "WONTFIX" because they are probably due to something that Eclipse relies on, such as the JVM or Carbon. This sort of thing has come up before in bugzillas and the conclusion has always been "don’t blame us, go talk to Apple"…or something about the event loop inside of Cocoa. I’m not a Mac GUI person. I just want Eclipse to work better on my Mac. Is that so wrong?
February 28th, 2007 at 12:51 pm
I bet it was easy to make those nice screenshots on your Mac, though.
But to the real point, for Ruby on Rails development, I think Eclipse on the Mac works well using the RadRails plugin. Plus OS X is just beautiful compared to Windows or GNOME/KDE/Linux. On the other hand, getting Ruby and Ruby on Rails, and (good god) ImageMagick/RMagick all configured in OS X is a super pain whereas in Ubuntu or Gentoo it’s a snap.
March 1st, 2007 at 3:30 am
Overlapping text editor line decorations – I have had exactly the same problem on Windows.
March 1st, 2007 at 10:00 am
Ken,
Lots of interesting stuff here. Do you want to go through the list, item by item?
Steve
March 2nd, 2007 at 9:27 am
Sure Steve, that would be fine. Or we could go over it in person next week at EclipseCON.
March 2nd, 2007 at 10:05 am
I won’t have a Mac at EclipseCon so I won’t be unable to fix anything.
1) Fixed.
2) Fonts in trees and tables should be the same or smaller than other Mac apps. Check the Finder. Enter a bug showing good fonts in a native app.
3) WORKSFORME. Esc doesn’t work for you? Enter a bug with the set of steps that make it happen.
4) The first one is a Mac bug we can’t work around (you can enter a bug if you want). The second is Eclipse ignoring the compute size we give it because it thinks the scroll bars will be auto hidden and shown (Mac doesn’t do this). Enter a bug against Eclipse.
5) and 6) … What can I say? If you run stand alone SWT apps, they don’t have wierd delays.
7) This is a bug in Eclipse. They draw the decorators in the wrong order. Enter a bug against them.
No idea about this one. If you ever get a set of steps, enter a bug. The browser is a cocoa widget and this sometimes has clipping problems.
9) Fixed.
BTW, when you enter bug reports, attach your screen shots. CC me on the SWT ones.
Steve
March 2nd, 2007 at 12:16 pm
Does anyone here know if OS X supports tear off views? I do not have an OS X system handy. I was given a Mac-using colleagues tips. He has the 30″ Cinema Display so I thought he might like this feature. However, it does not work for him. He gets the visual drop cue as if it will work, but then it does not.
Thanks
Mark
March 2nd, 2007 at 12:49 pm
Hi Mark, yes, I’m seeing the same thing. The cursor changes to signify tearing the view out of the window, but releasing the mouse button causes no change.
March 2nd, 2007 at 12:58 pm
Steve,
Great! Thanks for your response. When you say ‘fixed’ does that mean it been fixed in 3.3 is should work in the latest milestone build? I will enter bugzillas as you suggest.
Regarding #3, create a new java project. In the first wizard page after entering some text for the “Project name” field there are for buttons avaiable for selection; Back, Next, Cancel and Finish. How can I select Back/Next by using hotkeys?
Also, can you comment on Mark’s point regarding detachable views?
Thanks again for your time
Ken
March 2nd, 2007 at 1:57 pm
On the issue of Fonts, I think that SWT/Eclipse is using the “right” fonts in terms of using the same thing as the rest of the system. I think the problem is that in the context of the design of the Eclipse UI, the fonts are just too large and overwhelm the UI making it less usable than on other systems.
I do not know if Eclipse/SWT just choosing to use smaller fonts is really the right answer. Perhaps the Eclipse platform just needs to make it possible and simple, for the user to customize the fonts to their preference, rather than just using the system fonts.
Mark
March 3rd, 2007 at 11:39 am
Fixed means we just fixed it. Get a nightly or the next integration build and try it. Also, tear off views should work too.
Regarding #3 (again): How do other Mac apps do it? I don’t have a Mac here but you need to enable something somewhere in the preferences order to see the focus ring in buttons. It’s an operating system setting.
Steve
March 3rd, 2007 at 11:42 am
RE: Fonts
This has nothing to do with SWT. You can set the font in an SWT tree and it will use it.
Steve
March 6th, 2007 at 9:30 am
Regarding #3 (again) it seems that you can only shift focus with Tab to select the approproate button. It seems Camino has some special dialogs that let you type the first letter of the button. I assumed this was OS X but it seems to be isolated to Camino.
March 11th, 2007 at 4:29 pm
Ken,
Did you get the latest and try it out to make sure the SWT fixes are in?
Steve
March 12th, 2007 at 7:08 pm
Steve, I am still sorting through EclipseCon aftershocks and follow ups. I will verify and post new discoveries soon.
Thanks!
ken
March 14th, 2007 at 2:00 pm
On dismissing OS X dialogs:
The official Mac UI guideline, I believe, is:
- alerts and dialogs come up with some make-it-go-away button (like “OK”) focused (throbbing blue), so pressing return makes that happen
- if there’s such a distinction, there should also be a cancel button (go away without doing anything), and it has secondary focus (blue outline), so space-bar makes that happen
- cmd-. dismisses the window (same as cancel, where there is such a thing)
- tab moves the outer border (secondary focus) among active controls, in a loop. That would include any entry fields as well as the OK and Cancel buttons (and any other buttons there might be)
It is common, but I believe unofficial, to also have ESC do the “cmd-.” or “cancel” dismiss, to help the “switchers.”