After the break up ...

"A lot of people knew I left. I was a fool not to do what Paul did, which was use it to sell a record." John Lennon (1970)

Steve

More from the archives

Good lord, my office was full of shit.

Thanks to Jim des Rivieres for pulling out his camera and documenting some of the artifacts that we found there. There's a lot of OTI and IBM history amongst the rubble as well as a few things I thought were funny over the years. I could explain it all but that would detract from the fun.

Steve

Artifacts from Steve's Office

Can you believe that someone thought this was a good idea?

Steve

Message from your Emperor - PLEASE READ - ACTION REQUIRED

Well guys, it's been a long fun strange trip. I've had a great time over the years with SWT and Eclipse, but it's time for this Sith Lord to be invading new galaxies.



Over the years working on Eclipse, there have been many high points and a few low ones. Making everyone laugh at JavaOne during the height of the "Swing vs SWT wars" was really fun and helped ease the tension. Around that time, there was a full time blogger or two, FUD'ing and crapping on the toolkit and me personally (it seemed) for daring to make a few operating system calls. Who would have believed that?

The best part of the job was working with everyone at OTI and IBM and meeting all sorts of different people from all over, either in person or through the bug system. Eclipse is a place where (almost) everybody plays and thanks to the Foundation and others in the community, this creates a lot of opportunity. Great work guys!

It's never a good time to leave, but right now is a clean point. We are about to ship Eclipse 3.5 and this is the best time for me to untangle myself from my commitments. Silenio Quarti will be taking over as SWT team lead at IBM and he is one of the greatest engineers I know.

June 12th will be my last day with IBM. I've accepted a position at Bedarra Research Labs. The exact details have yet to be nailed down, but after a short break, I'm looking forward to new engineering challenges.

Best wishes to everyone and thanks,

Steve

P.S. I can be reached as steve_northover confuse a spam bot somewhere near "mail that is hot" should there be an attack on the death star from the rebel base.

You heard Ian!

Everyone that makes a donation of US$35 or more receives special ‘Friends’ benefits. So pay up and become "Friends with Benefits" with Eclipse!

Remember, "Friends get it sooner and faster."

Steve

Eclipse on Cocoa now full of sheet!

Ok, we are crazy but you have to live on the edge every once in a while to prove that you are still alive. Therefore, as part of the polish pass for Eclipse 3.5, we implemented Mac sheet windows.

A sheet is a temporary dialog that is attached under the title bar of the parent window like this:



The idea behind a sheet is that the parent window and the sheet are tightly coupled and won't get lost in the window stack. On Windows and other platforms, this is achieved by bringing all windows that are blocked forward, along with the dialog, when the user clicks on either the dialog or a blocked window. With a sheet window however, there is no visual confusion or mess on the desktop. The sheet is contained within the parent window.

When sheets were first introduced on the Mac, they frustrated me. They appear with a wondrous sliding animated fanfare (whoosh!), prompting me while simultaneously blocking the content I need to see to answer the prompt. Thanks a lot! At the time, I considered this a typical case of style over substance but since then, I have lightened up and just hit cancel like everyone else.

When is a dialog a piece of sheet?

At first we thought that all dialogs were sheet, but we were wrong. There are dialogs in the world that are not sheet, for example, wizards. Then we thought all message boxes were sheet, but that was wrong too. A message box that warns of a preference change and offers to restart Eclipse is not sheet.

Bottom line: You need to decide which of your dialogs are sheet. Eclipse can't do it for you and neither can SWT.

To implement sheet, we added a single style bit SWT.SHEET that you can set on a dialog when it is created. This is typical SWT: a tiny API exposes tons of functionality. For example, the underlying Cocoa API for sheets has a special API to hide and show sheets rather than overloading the regular window hide and show API. We chose to use a style bit and keep the Control.setVisible() API the same.

Steve

Lots of good stuff at EclipseCon

There was a ton of interesting stuff this year at EclipseCon but my favourite was Kevin McGuire and Tim Wagner's key note, "Darwin Among the IDEs". We are often so mired in our day to day work that we fail to step back, evaluate where we are, where we have come from and where we might be going. Keynotes are supposed to make you think and this one took my mind off throbbing default buttons and Mac toolbars that didn't make M6.

During the "e4 in Review" talk, people were asking about backward compatibility with 3.x and Martin Oberhuber stressed that Eclipse was a platform and then innocently asked, "What would happen if Windows suddenly stopped running our old programs?"

It took a second for the room to get it and then explode.

Steve

Fighting the Cocoa default button!

On Mac Cocoa OS X 10.5, the throbbing default button animation is implemented as a separate thread that calls drawing methods directly from that thread. You would think that this wouldn't be a big deal but threads in a GUI toolkit are always a big deal.

It's an amazing GUI toolkit 101 blooper!

Who cares if the default button is painted from another thread? First off, SWT checks thread accesses to avoid operating system crashes. First attempts at a fix removed this check, causing operating system crashes.

How about hacking so that drawing requests from the throbbing thread are serviced, but don't run any SWT listeners? No good. The Mac user-interface is composited so parents of the button are asked to a paint all the way up to the shell and the button paints last on top of them.

Can't paint ... but must.

It seems that there are only two fixes:

1. Lock and allow the throbbing thread to run as the Cocoa Gods intended
2. Throb somehow safely in the UI-thread

Since introducing locking everywhere in SWT at Eclipse 3.5 M6 and hoping that it works at this point is insane, all we can do for now is attempt to throb safely. This fix involves remembering that you were asked to throb, telling the operating system that it has throbbed already and then later throbbing with impunity from the user-interface thread.

Steve