One of my favorite movies of ‘07 was “Ratatouille” from Disney.  In it, there is a character named Chef Gusteau who’s sole message in life was “Anyone can cook!”.  And in the movie, the theme plays out with a rat becoming a star chef in France.

I loved the theme because it’s very close to how I feel about what we’re trying to do here at Bug Labs.  I would modify the theme slightly to say something like “Anyone Can Build a Gadget”, but the intent is exactly the same.

One of the most gratifying things about working with groups like Human Rights Watch on this UCB Mobility Challenge project is that they have taken this to heart.  They can build a device of their own.  They don’t have to become a big hardware developer, or raise tens of millions of dollars.  They don’t have to learn how to solder or become solid state electronics experts.  They can just build a gadget.  And use it for what they want.  I think that’s enormously liberating.

I firmly believe we will see much more of this in the coming quarters.  Companies, organizations and individuals that you would have never thought would be in the “gadget business” will suddenly start building and selling very custom/personalized devices.  Amazon’s Kindle is a great case in point.  It is a great trend that will benefit everyone.

Bug Labs was at the Austin Maker Faire this weekend, where we won a Editor’s Choice award from Make! We were really honored to be part of Maker Faire and excited to show everyone our product!

Just before Maker Faire, at our Open House, we got our breakout board module (The Von Hippel) talking to an Arduino mini! It was a collaborative effort with help from NYC Resistor, who brought us a much needed R232 to TTY chip at a moment’s notice.

The folks at Maker Faire enjoyed clipping together modules together and coming up with new module ideas we should consider for the future, such as the Jelly Bean module and a Robot Wheels module (pictured below).

Hope everyone enjoyed seeing demos of the Bug! If we took your picture with the DrawPad app, check for it on Bugnet!  View more pictures of Bug Labs at Maker Faire here!

One thing we’ve had in the works for a few months now are some tools to integrate OpenEmbedded and Poky with Eclipse.  We are a big fan of Eclipse as a modern development tool and use it as the foundation of our Java-based SDK.  Poky (based on OpenEmbedded) forms the foundation of the BUG Linux operating system.  In addition to making Java and OSGi apps easy to write, we’re also adding tools to make it easier for those of us that work down in the pipes.  Here is a screenshot of a BitBake recipe editor.  If you are interested in this kind of functionality, we’d love to hear from you!

We have released yet another production release of the Eclipse Dragonfly SDK – #6! More information is available here and you can download it here.

Aside from fixing some defects that magically got into the code, we added some important features as well (http://bugcommunity.com/wiki/index.php/SDK_New_and_Noteworthy_Features). One of these improvement makes integration with BUGnet work to the user’s advantage in the SDK. As BUGnet grows in the number of applications that are available to download and explore there is a need to sort out and present this information, after all this what we all are looking for – relevant information, isn’t this is why we love Google? This new feature is called ‘Applications by Modules’ and the idea is that once you connect your physical BUG or launch Virtual BUG a new section in BUGnet view will show relevant applications. The list of relevant applications is dynamic – so when modules are removed from or added to the BUGbase the application list will reflect that change.

Hope you are as excited about this and other improvement as we are! If you have other ideas – we are listening.

Please come by the Eclipse DemoCamp:

June 30th, at 7:00 pm
Spitzer’s
101 Rivington St (Map)

We’ll have Dragonfly SDK demo, some Bug Lab folks will be on hand, and we’d love to see you. Also, as always, you can share your ideas at our forums (http://bugcommunity.com/forums) or drop by our IRC channel #buglabs at FreeNode.

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!

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?

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:

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).

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?