Bug Blogger

Oh Hai from EclipseCON

What do I love more than lolcats?

Why, EclipseCON of course.

I've noticed a great deal of interest lately among Eclipse bloggers about Bug Labs and BUG, particularly given our involvement with the Eclipse and OSGi communities. So with the buzz about BUG growing, especially as we begin shipping soon, I'm pleased to announce that we'll be showing off the BUG and the Dragonfly SDK all throughout next week's event.

Angel, Alex, and myself will be at EclipseCon 2008 between Monday and Thursday, and attending as many of activities as possible. In addition to our BUG+SV next Tuesday and speaking at the show next Wednesday, we'll also be hosting a BUG+Hack event at EclipseCon on Tuesday and Wednesday. Bug Labs will be camping with Cloudsmith in their CloudLounge, located in the lobby of the mezzanine level of the Santa Clara Convention Center. Stop by, load up Eclipse and your OSGi bundles, and have some fun. There will be some great prizes in store (hint hint: a BUGbundle or two) for whoever makes the best BUG apps by the end of Wednesday.

On the OSGi front, there has been some interesting discussion on OSGI consoles. Looks like there should be a standard at some point soon. Have a wish-list or gripes? Might be a good time to check out the mailing list or come to a BoF (Birds of a Feather) session at the show, as I'm sure the topic will come up.

Lastly, I've been working on a personal project in PHP and gave the PDT project a try. Wow! The PDT team did a fantastic job. It's simple, elegant, and "just works". Reminds me of the profiler we had back in Eclipse 2.11. If you do any PHP development I highly recommend it.

Looking forward to seeing everyone at EclipseCON!

When do you stop teaching that old lolcat new tricks?

Here is a scenario that may be familiar to some Eclipse developers:

1. Write lolcats manager plugin using Eclipse x.y.
1.2 Build scripts for lolcats is written.  Takes 2x time of writing lolcats.
2. Release lolcats for Ecilpse x.y.
3. Eclipse releases x.z to general public.
4. Lolcats is tested on x.z and it is compatible. (yay!)
4.2 Lolcats build scripts are modified to build against x.z. 
5. You are now supporting Lolcats on x.y.* -> x.z.*
6. Users start sweating for bug fixes and new features only in x.z.
7. Brain starts hurting.

When do you stop supporting older Eclipse releases?  There are some great things in 3.3 that simply are not available in 3.2, and the overhead in forking product that goes through building, testing, and documentation can be very expensive.  Any advice on when to say when?

Eclipse/OS X Rant II

Steve and co have done a great job of addressing some of the issues (the ones that were actually relevent to Eclipse) in my previous entry on Eclipse and OS X. One EclipseCON and three weeks later have produced some more information that's probably better as a new post rather than continuing the comment thread.

Issues #1 and #9 has been fixed! I verified in the latest (I2007030313-1051) integration build. The menu fix in particular helps a great deal.

Comments on previous issues:

Item #3. This is an OS X issue. The dialogs don't have hot keys. I envy GTK users, as it looks like all the eclipse dialogs have hotkey mappings. The closest thing on OS X is to Tab to the appropriate button and press space.

Item #4. https://bugs.eclipse.org/bugs/show_bug.cgi?id=177405

Item #5. I agree that with the amount of information surrounding this there is no approach at a solution. And it's highly likely this has nothing to do with SWT. A friend suggested that Apple's JVM could be doing garbage collection differently, and that could be the cause. It does seem to happen more often when there is some sort of File I/O. And it can be pretty bad; locking up for minutes at a time.

Item #7. https://bugs.eclipse.org/bugs/show_bug.cgi?id=177407

Item #8. This is not a browser problem. It's always there, in both the latest integration build and in 3.2.1. But after some comparing with other peoples machines, it looks isolated to me.

Further Issues:

Toolbar Button Disable Image: On the mac the toolbar buttons that are disabled don't change color. At least toolbar bottons that act as combo boxes. In the following image some actions are disabled. I find it difficult to tell.

Combo/Text Boxes: This is a little hard to explain. Text focus is always right justified. Edit a field that has text that is greater than the size of the Combo Box. You cannot see any text to the right without using the mouse to reposition the cursor. This is one that you have to try rather than just see, but here is a control that exhibits the behavior, in the JAR export wizard:

Property Pages: Read-only text fields to not have proper spacing or borders, and sometimes render extra lines that are not the background color. This screenshot is from a property page for a Java project:

Property Pages #2: There is no context menu in read-only controls. You can copy with [Apple] C, but you cannot perform these types of operations via the context menu.

Inconsistencies with layout and widget borders. I think this screenshot speaks for itself. Some things have borders, others do not. Some have scroll bars, others do not. Layout and sizing are inconsistent. Group controls title text is too close to the checkbox above and not close enough to it's client composite (IMHO).

Buttons: Click at the bottom of a button. Nothing happens until about 5 - 10 pixels up.

General Notes: Regarding the overall asthetic value of Eclipse on OS X, some work could be done on how controls and layouts work. Text boxes seem to be the worst offenders. A stroll through the property pages in the Preferences dialog is a good way of seeing this. Overall I'm quite impressed with the response from Eclipse. Open Source is about the community, not the software.

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.

3. Modal dialogs!  Where art thou hotkeys!  I've tried every key combination I can think of to try and trigger these dialogs to go away without wasting precious energy to move the mouse.  This is really annoying, mainly because it seems like such a no-brainer.

4. Layout bloopers.  I can't say these are much of a problem really, but I've never seen anything like this on my Ubuntu box at home.  Notice how the tiny text at the bottom bleeds into the resize widget.  And what is that thing after the carrot!?  And notice on the preference page how the default layout doesn't contain enough space for the default preference items.

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?