Inside SWT

Flogging my FrankenMac

2011-10-04T18:37:00.003-05:00

I'm running a FrankenMac. It's a MacBook Pro with Windows 7 and Linux as guest operating systems.

For my talk yesterday, I was showing Fx running as an Eclipse plugin on Windows and Mac. I grabbed a few standard Fx examples, modified them slightly and dropped them in. Here is the ColorfulCircle example running in Eclipse:

For the demo, I had a total 4 Eclipses (two Windows, two Mac) and 6 Fx embeddings, each doing some sort of animation on my machine. The source Eclipses were full development environments with the source of Fx loaded into them. For extra fear, the Mac Eclipses were running JDK7. There were a few browsers running too on both operating systems and the slide software.

You might think that it would lurch, but it didn't. Incredible.

Steve

JavaOne

2011-10-01T18:30:00.002-05:00

I'm speaking at JavaOne this year with Artem Ananiev. The title of the talk is "Using JavaFX 2.0 UIs with Swing and SWT". I've worked with Artem in the past but never actually met him. That's always cool.

Most of the hassles around interop with Swing and SWT were around threading. It was possible to embed one toolkit in the other, but programmers needed to be very careful to avoid deadlock. The rule of thumb was, "never wait" and use asyncExec() and invokeLater() to communicate between the two.

I'm happy to say that FX and SWT have no such hassles. Both are apartment threaded and share the same apartment.

Steve

Joining Oracle

2011-05-09T14:38:00.000-05:00

I guess I've always been a UI guy and my attempts to deny it have failed! Don't get me wrong, I've been doing UI for the past couple of years but it's been on the application side. That was a great experience but it was time for a change.

Why join Oracle? Oracle isn't kidding. They are taking Java forward, removing roadblocks and doing whatever it takes. We've seen a few examples of this already. Oracle and IBM are working together. Oracle and Apple are working together and the Mac JVM is going to be better than ever. The old suspicions are gone and everyone is open for business.

At this point it's not quite clear exactly where I fit in but I'm an Eclipse fan and Oracle is an Eclipse supporter, so it makes sense to post here.

Now I'm off to fix some Swing bugs ...

Steve

After the break up ...

2009-06-11T21:01:00.003-05:00

"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

2009-06-10T20:57:00.008-05:00

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

2009-06-10T07:05:00.005-05:00

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

Steve

Message from your Emperor - PLEASE READ - ACTION REQUIRED

2009-06-08T07:09:00.001-05:00

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!

2009-05-21T21:50:00.003-05:00

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!

2009-04-24T17:45:00.003-05:00

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

2009-03-28T11:06:00.004-05:00

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!

2009-03-02T17:48:00.003-05:00

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:

Lock and allow the throbbing thread to run as the Cocoa Gods intended
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

Goodbye early access for Mac cocoa

2009-01-28T11:47:00.002-05:00

The SWT team has been working really hard to complete the Mac cocoa port for Eclipse 3.5. As is typical with these things, about 95% of the code works but it's the last 5% that makes all the difference. What's in the 5%? The usual crashes, performance problems and stupid bugs that make things look bad, when in fact they are pretty good.

Here are some bugs that have been fixed recently for Eclipse 3.5 M5 (253227, 260929, 261854 and my personal favourite 251021). Some didn't make it because there wasn't enough time to get to them (260592) but we'll be looking into them and more for M6.

Special thanks go to the committers Kevin Barnes, Grant Gayed, Scott Kovatch, Silenio Quarti and Felipe Heidrich as well as the community for testing and reporting bugs. We aren't done yet. As more people start running the code, we're going to see more problems and more crazy fixes in the code.

Stay tuned!

Steve

Too many meetings ...

2008-12-12T22:53:00.001-05:00

Remember folks ...

Steve

Smog Computing

2008-11-29T20:16:00.002-05:00

Announcing smog computing! I don't know about you, but I'm heading for the clouds. Enough computing on earth. The bits are much more delicious here in the stratosphere. Up here, a guy can really click on a button. It's different. It's better.

Now to get here, I had to endure fog computing. That was me, in a fog, wondering where everything was. Where are the class hierarchies? Where are the visibility rules? Where are the components? But the fog cleared ... and here I am (cough, cough).

Listen up ground dwellers, Douglas Crockford says, "I have been writing JavaScript for 8 years now, and I have never once found need to use an uber function. The super idea is fairly important in the classical pattern, but it appears to be unnecessary in the prototypal and functional patterns. I now see my early attempts to support the classical model in JavaScript as a mistake."

Steve

You gotta love the Mac!

2008-10-10T10:16:00.002-05:00

For shear diversity in getting things wrong, the Mac wins. Windows just crashes or locks up, but the Mac fails creatively. The other day, I was giving a presentation from Mike Wilson (McQ)'s office using his Mac and this is what happened:

This failure is wonderful. If it has just drawn everything sideways rather than up and down and sideways, I could have tilted my head to read it.

Steve

The GUI world is a mess

2008-09-14T09:17:00.000-05:00

It's no secret that the GUI world is a mess. It was bad on the desktop, but it's worse on the web. Products that have both a desktop and web presence need to build and maintain both. That's two messes instead of one.

Web and desktop applications, though maddeningly similar, have certain key differences. First off, there are two fundamental types of web applications. The first and the majority, are traditional hyperlink-based applications. They provide access to remote content using the familiar "document browsing" web metaphor. The second and the new breed, are desktop-like applications that create and manipulate complex content. They use the familiar "stay in the same window" desktop metaphor. Hybrids of the two are possible.

Desktop-like web applications, especially AJAX ones, are difficult to build, debug and maintain. That's why there is such excitement over things like web spreadsheets and word processors that, while functional, are so basic they would be laughed off the desktop.

This concludes today's edition of: Stating the Obvious.

Steve

Back to work!

2008-09-11T07:43:00.003-05:00

Ok, so now it's September, the vacations are over we are on the hook for both Eclipse 3.5 and e4 work. The planning is coming to an end soon and the work is about to begin (not that people haven't been working all along).

For SWT, there are lots of fun and interesting things going on. The cocoa port will be real. My old friend Scott Kovatch of Adobe and Apple fame is working with us daily, not just submitting patches but owning and implementing entire areas. For those of you watching the last little while, the cocoa port is classic SWT. Hack, get a pile of code working, step back, evaluate, refactor, fix the tools, hack, get a pile of code working, step back, evaluate, refactor ...

I'm hoping to get back to blogging more regularly. Not that you care, but it's always fun when I say something stupid, like "The worst platform in the world is Mozilla", the subject of my next post.

Steve

I have a theory ...

2008-06-24T07:35:00.000-05:00

... that methods come in two flavours.

The first flavour is simple. For example, methods like runMessages() consist of an iteration that runs each message. Heck, they might even send run() to each element in a list, but they don't do much else. They are trivial to understand and easy to see working.

Then there are the complex kind. These are the hairy long methods that do interesting work. They might be inlined, access the representation directly and have a ton of local variables and switches. These methods need to be decoded each time you see them.

The assertion is this: If your code is all simple, then control is too decentralized and your program might be large and slow, making it difficult for others to understand, maintain and debug. If your code is all complex, then control is too centralized and your code is a mess, making it difficult for others to understand, maintain and debug.

A good program has the right mix of both.

Steve

Fix only the one place

2008-06-03T06:58:00.001-05:00

Like Sergent Pepper's Lonely Hearts Club Band (Reprise), "It's getting pretty near the end" for Eclipse 3.4. As always, there is a stream of bug reports coming in, 99.9% won't get fixed for this release.

We did fix 235219 yesterday (Cheese in tree). It was a regression from 3.3 that had a big visual impact on Eclipse. Amazingly, it was only reported just now. The underlying problem was that the Windows message TVM_GETVISIBLECOUNT returns only the fully visible item count of a tree and we made the mistake of thinking that it included the partially obscured item at the bottom. The fix was to change a "<" to a "<=".

TVM_GETVISIBLECOUNT is used in other places. After a careful analysis, we decided that we wouldn't change them. The code is wrong, but we've done our testing, the impact is low and it's too late. Better to fix only the one place and leave bugs in, than blow the release.

Steve

Schindl's list

2008-03-22T11:51:00.000-05:00

If you've ever been on the list, you'll know it. The one I'm talking about is Schindl's list. Tom Schindl finds the bugs, reports them, patches when he can and forces the fixes through. Thanks Tom. The list is life.

Steve

The fake Steve Northover

2008-03-19T00:53:00.000-05:00

The fake Steve Northover will be attending EclipseCon tomorrow and showing up at random in some of the talks. You will be able to tell the real one from the fake one easily. The fake one cannot play the guitar and will use manager-speak, saying things like "break down the silos".

Meanwhile, the real Steve Northover is at home, working on e5.

Exciting news!

2008-03-14T23:00:00.002-05:00

We've begun working on e5, the new generation Eclipse platform based on e4. It will be written from top to bottom entirely in XML because the brackets have officially changed.

In case you don't know what that means, first the brackets were Lisp (), then Smalltalk [], then Java {} and now XML <>. The code between the brackets is about the same, except in the XML case where math is not allowed.

All work is being performed behind closed doors in a evil lair.

Steve Northover
"... not the best community relations expert"

I'm speaking at e4Con

2008-03-07T20:44:00.001-05:00

Holy crap, what a bunch of trouble I caused. I'm not going to comment on the whole e4 thing because McQ and others have done this already way better. The fact is, we're looking for smart people to help define e4 and work on it.

It could be you.

I'm a friend of e4! Donate to e4!

Steve

My talk was accepted

2007-12-21T08:19:00.000-05:00

I'll be giving a long talk on SWT 4.0 at EclipseCon 2008 with Silenio Quarti, committer, technical lead and programmer extraordinaire. We're planning to explore today's fragmented GUI space and sketch out some possible futures for SWT. See you there!

Steve

Insights and insults from GTK ...

2007-11-29T00:35:00.000-05:00

Got this the other day while running Eclipse on Linux:

** (SWT:5087): WARNING **: Some clown returned undeclared exception 'IDL:Bonobo/BadArg:1.0'

That's it, I'm upgrading SWT's error messages to be more helpful and informative. How about, "You turd, you can't access a widget from outside the display thread"?

Steve

Assmetrics

2007-11-20T09:57:00.000-05:00

I'd like to coin a new technical term: Assmetrics. As you might imagine, an assmetric is exactly what you think it is. Programs are full of them but my favourite these days is from the slash and burn Mac cocoa port. If you don't resize a combo box to be exactly 26 pixels high, you get this message at runtime:

2007-11-20 10:17:26.452 java[4523:10b] This application is trying to draw a very large combo box, 100 points tall. Vertically resizable combo boxes are not supported, but it happens that 10.4 and previous drew something that looked kind of sort of okay. The art in 10.5 does not break up in a way that supports that drawing. To avoid breaking existing apps, NSComboBox in 10.5 will use the 10.4 art for large combo boxes, but it won't exactly match the rest of the system. This application should be revised to stop using large combo boxes. This warning will appear once per app launch.

By the time the guy who implemented NSComboBox typed all this in, he could have just centered the thing.

Steve

Ok community, blow your brains out

2007-11-17T08:17:00.000-05:00

As many of you know, a ton of Mac cocoa work was taking place over the last two weeks. We have now folded the lot from the cocoa_work stream into HEAD. At this point, despite the astounding progress that was made (including porting the browser), there is no more time to work on it.

Right now, by commenting out NSObject.release() and using dark magic to get around the fact that there is no launcher, Eclipse comes up. Obviously, we are freeing something we shouldn't and crashing because of it. As you can imagine in a prototype that was developed so rapidly, there are many bugs and unimplemented features but ... holy shit, Eclipse starts.

Please contact us on platform-dev-swt to find out how you can help.

Steve

Great-a-success!

2007-11-09T03:56:00.000-05:00

Here is the ControlExample running under cocoa:

We started on Monday with nothing. Along the way, we hit an Objective-C compiler bug involving struct return types that caused a series of Apple trolls to visit us, each one expressing increasing disbelief. No problem though, I love these low level compiler guys. They are smart and fun.

But crashing didn't stopped us. We just typed in custom natives each time we hit the problem and kept going. Eclipse allowed us to develop rapidly, almost as fast as the old Smalltalk days. Objective-C has lots of good stuff from Smalltalk like real meta-classes (Java static methods are crap) and dynamic dispatch.

The week was an almost perfect example of prototyping. The code we have is utter crap and we have cut every corner, however, we have learned the technology and explored the area. Prototyping is about reducing risk using a short term, high energy, low quality approach to prove that a solution is possible and scope the time frame.

Steve

Hacking at Apple

2007-11-07T23:51:00.000-05:00

Silenio and I are at Apple this week. We were invited to take a course which turned out to be a cocoa hack-a-thon. It's a good deal for me because I get to code and get away from distractions at IBM.

As many of you know, cocoa is Objective-C and SWT is programmed from top to bottom in Java (otherwise, we couldn't possibly develop or maintain the toolkit). So the first order of business was to figure out how to call Objective-C from Java. We needed to convert this:

[object message: 12];

into Java.

Obviously, we could have a billion natives, one for each message, but this would be too crazy, even for us. So we got the compiler to dump the assembler to see what was going on. It turns out that everything is a call to objc_msgSend() so we typed these guys in and were on our way.

On Monday, Scott Kovatch (my friend at Apple) said, "Hey, we've got a description of all this stuff in XML". He showed us where it was and by the start of the next day, Silenio had all of the selectors and classes that we needed. So instead of typing:

OS.objc_msgSend(id, OS.sel_message, 12);

we were typing:

object.message(12);

Everyone else in the room thinks we're insane.

Steve

If I read this one more time, I will puke ...

2007-10-29T23:27:00.000-05:00

Yesterday, I read yet another person quote Knuth saying, "Premature optimization is root of all evil". Knuth wrote that in 1974 in the era of punch cards. Over the years, I've seen this statement used to defend bloatware, slugware and complexware. I'm tired of it.

Of course, when you are prototyping, don't be concerned with performance because you are prototyping. At the same time, if there is something simple you can do to be faster, do it! That way nobody has to come back later and optimize your code.

Steve

Lots of gradients, less functionality

2007-10-16T09:16:00.000-05:00

If you use Hotmail, you'll notice that recently the user interface has changed. It's now super cool and gradient filled. The new login is spiffy and exciting, AJAX enabled and hover happy. Here it is:

You'll also notice that if you have multiple Hotmail accounts, it's less functional. Click 'Sign in with a different account' and you get something similar to the old login:

Now you get to type the new email address in again, rather than editing the old one. Isn't that great? Microsoft, keep those gradients coming.

Steve

Armillaria Ostoyae

2007-10-11T12:32:00.000-05:00

Sometimes I feel like I'm part of Armillaria Ostoyae, the worlds largest living thing. No surprise, it's a fungus that sneaks around underground, killing trees by the roots.

What caused this revelation? I was shown a presentation where Eclipse (and SWT by proxy) was a tiny little box in a huge diagram that resembled modern art. I know how big SWT and Eclipse are. I'm part of the fungus!

Steve

Backpfeifengesicht

2007-08-21T19:41:00.000-05:00

German for a face that cries out for a fist in it.

As part of the "API is forever" philosophy, SWT committers spend a lot of time exploring naming, package visibility and the way an API works, a long time after the code works. There is always tension between the smallest number of classes, methods and constants needed to get the job done, consistency with similar concepts in the toolkit and the future. The future is important because "API grows like fungus", however twisting today's API for a future that may never come makes today's API cumbersome and hard to maintain. So, before an API makes it out, we've considered the likely futures and have concrete ideas about what we will do should they arise. As you can imagine, all this discussion is very stressful.

I love the fact that the Germans have a word for something I feel every once in a while.

Steve

API grows like fungus!

2007-08-01T08:12:00.000-05:00

When you define an API, if you think you are done or have covered all the cases, you're dreaming. API grows! Fortunately, there are lots of things you can do to ensure that this can happen, without resorting to the dreaded IWhatever2's.

Consider this interface method:

public void onKeyPress(Widget sender, char keyCode, int modifiers);

What's wrong here? First off, 4-byte Unicode is coming and char's won't cut it. Secondly, suppose I want to add the concept of raw keyCode (for example, to distinguish between and unshifted 'A')? There's no place for that information. How about the concept of a forwarder (ie. this key press was forwarded to this widget from another widget) or a "doit" flag to cancel the operation? Not possible.

Fortunately, the fix is easy. The method should take an object rather than a list of parameters. The object is free to grow methods and fields without breaking the method signature.

public void onKeyPress(KeyEvent keyEvent);

Seems obvious, right? Not really. This method comes from GWT. They have shipped and cannot make these sorts of changes to this method without breaking people.

Steve

It just works

2007-06-09T11:08:00.000-05:00

The other day I remoted in from home to my Vista machine at work and noticed that the caret had stopped blinking. At first I thought it was a bug, but when more of the Vista animations weren't there, I realized that it was a feature.

Animations take bandwidth and Vista was degrading (gracefully) to give me better performance. Of course, Eclipse, RCP, SWT and other native applications get this right.

It's always cool when I find another feature that "just works". So many things just don't these days.

Steve

Analysis Paralysis

2007-05-31T08:50:00.000-05:00

I've seen this happen to people before. They are given a problem with some really thorny cases and they thrash. Me, I think with my fingers.

Thinking with your fingers can be dangerous. For example, the first code you write, the first code that solves the problem, is never the right code. Thinking with your fingers involves refactoring. Sometimes you need to throw everything out and start again but this time, you know the problem space.

You can thrash with your fingers too. You'll know when you are thrashing. You hack and get nowhere. Everyone has experienced that sinking feeling. When that happens, turn the computer off! Go talk to someone, google or read a book. You are not alone.

There is another version of analysis paralysis that affects managers. It leads to defeating meetings, phone drone and endless email. I won't discuss that in case I get fired. Besides, I don't want to limit my advancement opportunities.

Steve

I hate Windows

2007-05-22T21:47:00.000-05:00

Ok, now I have your attention: I don't really hate Windows (any more than the rest of them). So what did Windows do to me this time you ask? We were looking good for Eclipse 3.3 RC2 when this came in.

On Vista only (win32, not WPF) , it turns out that TVM_GETNEXTITEM is really slow when called with TVGN_LASTVISIBLE during a tree item collapse when the item that is collapsing has more than 23 children and each child has at least one child and the collapsing item that started the whole thing going is about to become the new absolute last item in the tree. All this has to happen during a WM_NOTIFY for custom draw (NM_CUSTOMDRAW with subcode CDDS_POSTPAINT) or it's not slow. You got all that?

Obviously, we have a broken fuxit .... as in, "What the fuxit doing?". My guess is that some cache way down deep in Windows is getting invalidated and someone is linear searching every item in the tree multiple times.

Fortunately, SWT has no custom C code (yay!) so it was pretty easy to find the system call that was taking the time and come up with a work around. Even though the work around code will run on XP, I'll probably guard it with a test for Vista. After all, we're closing in on RC2. Gotta be careful.

Steve

Is that new IDE feature worthwhile?

2007-05-15T09:05:00.000-05:00

I'm a simple guy and live by simple rules. One of them is: "That which obscures my code is bad". This rule isn't hard and fast, but generally turns out to be true.

For example, the red squiggles that show up under your code (sometimes called "the red sea") are good. They tell me I have compile errors and let me see my code at the same time. Automatic Javadoc or code assist (sometimes called "code desist") is bad. It can steal focus, misdirect keystrokes, obscure code, insert random text fragments, slow my typing and most of all, confuse and frighten me. It's a completely different story when I ask for it. Then I'm not afraid.

It's hilarious watching people give demos, fighting with their IDE as it inserts unwanted code fragments which they immediately delete. Fortunately, Eclipse allows you to configure everything so you get to choose whether you are being helped or hindered.

Steve

Announcing Avaj!

2007-04-17T07:36:00.000-05:00

Avaj is a new strongly typed object oriented language. It features C syntax, a garbage collector and many other advanced features. The designers of Avaj know that "API is forever" and "@deprecated is a lie". Therefore, Avaj has a compact class library, starts fast and has a small memory footprint.

Classes in Avaj are real. The concepts of "class" and "type" are the same. Each class has a meta-class to describe the class and support inheritance on the class side. Types that are built-in, such as "int" or "float" and concepts like arrays, are modeled by Avaj classes (although highly optimized at runtime).

The designers of Avaj built on their experiences with other computer languages. For example, dynamic languages like Lisp and Smalltalk have closures, making concepts like iterators and inner-classes obsolete. These constructs and other redundancies were not added to the language.

Unfortunately, all work stopped on Avaj when it was determined that no one could make any money off it.

Steve

No code nirvana

2007-04-05T08:41:00.000-05:00

The other day, I was reviewing our coop's code (a coop is an intern for those of you from the states). We get great coops who are smart and work hard and this guy is no exception. I always ask the person to clean up their code before I get there and make sure it's good.

It is normal for me during the review process, even after cleaning, to delete 10 to 50% of the code, without removing any functionality. Some of it is unused variables, dupicate state, things that are stored instead of computed and all the usual things that cause "too much code". However, a surprising amount of it is simply duplicated or unnecessary work. Why?

SWT committers are rewarded for implementing functionality, not writing code. We take pride in having the minimum amount necessary to do the job and strive to reach "no code nirvana" (an impossible state). Perhaps you reach it when you become a manager?

Steve

Insights from the Xlib Programming Manual

2007-03-28T08:25:00.000-05:00

If you think X is dead, you are wrong. Widget toolkits like GTK try to hide it, but in the end, X is still the thing that handles events and puts pixels to the screen. Sometimes we need to reach through the muck and program it. Bogdan Gheorghe, a committer in training, discovered this the other day in the official Xib Programming Manual (it's been there from day one, I knew it was there but had forgotten):

Virtual Focus Crossing and the detail Member

We will now embark on specifying the types of events sent to each window and the detail member in each event, depending on the relative position in the hierarchy of the origin window (old focus), destination window (new focus), and the pointer window (window containing pointer at time of focus change). Don't even try to figure this out unless you have to.

At least these guys are honest, but how about defining API that is simple enough that it doesn't need to come with a warning?

Steve

BYTE Magazine, January 1997: "Can Java Replace Windows?"

2007-03-21T07:29:00.000-05:00

IBM Labs Ottawa is cleaning out the old OTI library (a long time ago, we used to be OTI). I found a BYTE Magazine from January 1997 with the cover story, "Can Java Replace Windows?". Interesting that it is now 10 years later. I'd forgotten just how much hype there was at the time.

Here are some titles of the articles inside:

"Today the Web, Tomorrow the World"
"Why Java Won't Repeat the Mistakes of Unix"
"The Bitter Taste of Java"
"Corel's New PDA and Java Suite"
"Java to Power Flying Car"

Ok, I made that last one up.

Steve

Useless dialog of the day

2007-03-15T08:11:00.000-05:00

Carolyn Macleod, accessibility wizard, was starting up Eclipse M-whatever yesterday and got this:

How useless is that? What file changed? How do you answer this question? At least tell me the file name.

I'm seeing a trend in software these days: attack the user with dumb dialogs. If you must attack, at least tell me something useful, like "All your base are belong to us".

Steve

This blog has been accused of having no content

2007-03-10T10:29:00.000-05:00

The software Gods and the global cache

2007-03-08T20:35:00.000-05:00

How many times have you done this: Scrolled through the code, saw something totally bogus, fixed it, and then got a bug report from someone just discovering the bug you fixed. This has happened too many times to be mere coincidence and it's not just bug reports. Discuss how you might implement a feature, and someone will request it right out of the blue.

I believe there are software Gods who maintain a global cache of all project activity. When you think of something or touch the code, the cache gets updated and someone gets notified.

Steve

Refuctoring your code

2007-03-02T21:29:00.000-05:00

Have you ever done this: Tried to refactor your code ... and failed.

Amongst the many masterpieces that sit at the bottom of the Eclipse stack, SWT is one of the gnarliest. Implemented in Java, it's coded to the metal. Many things are inlined. It's full of version checks, work arounds for operating system bugs and wild hacks that make everything go. It's backwards compatible to the day it first shipped, yet somehow embraces and exploits the latest operating systems features.

Don't be afraid. This is normal for a high performance, operating system level library that isn't waiting for the hardware to get faster.

Anyway, while attempting to refactor some of the more crufty code, I failed. The refactored code just wasn't any better so I ran away from the changes. It took strength to step back, evaluate the situation, weigh the pros and cons and decide to throw it away. Really, you are throwing out more than code. It's the investment in the new way of thinking, rather than the changes, that you have trouble parting with.

Code that is refactored into worse code: that's refuctoring!

Steve

It's the end of an era

2007-02-28T09:55:00.000-05:00

Here is Zoomin.exe, a pixel magnifier, running on Vista:

Microsoft finally broke this program. It runs, but no longer sees the screen and only magnifies itself. If you look closely, you'll see it's a 16-bit Windows 3.0 program. Microsoft shipped it as part of the Windows SDK circa 1990.

Do I care that it's broken? Nope, only cavemen (and possibly Voyager) are running applications this old. There are many, many, more and better programs like this around, but I kind of got a kick out of running this one. It's only 7K. No DLL's, resource or config files, yet it has an icon . It really is just a 7K EXE.

In my youth, I once built a Digitalk Smalltalk/V program that did the same thing. I used the tools of the day to throw out almost everything and managed to create something that was 37K. Of course, it needed the VM DLL's, but they were tiny too. I remember being mad when I figured out the Smalltalk VM was taking 256K at runtime (probably for the garbage collector old and new spaces).

For me, Zoomin.exe was kind of a test that Microsoft passed, year after year. The program is 17 years old and is only now broken. Imagine trying the same thing with a Linux distribution.

It was also a reminder. GUI programs could be tiny. Oh computing world, where did we bloat out and go wrong? I guess I'll have to get my kicks some other way.

Finally, this is the sort of backwards compatibility that we aim to achieve with SWT, despite the fact we run on Linux!

Steve

What happens when you don't fix a critical bug?

2007-02-23T10:37:00.000-05:00

For a while now, there were a number of problems in our OLE support. The worst was 49098. Some controls, such as Microsoft Word, wouldn't show scroll bars. I'm happy to say that this bug and a bunch more long standing OLE problems have been fixed.

What happens when you don't fix a critical bug? Smart people find work arounds. For example, IBM wrote the IBM Container for ActiveX Documents. By using the OLE support in MFC, they were able to work around the problem. Why didn't we do this? SWT doesn't use MFC for performance, memory and maintenance reasons. We couldn't throw out our existing code or the SWT OLE API. The fact that we had no idea what MFC was doing to fix the problem and no one could tell us cinched the deal.

Other people began to investigate and use DSOFramer, a Microsoft control that embeds Office documents. This wasn't ideal, but it did solve the sizing issues.

I'm not proud of these work arounds, but at least open source makes them possible. The design pattern that SWT uses is "just write the code" so people can see what we are doing and where we are doing it.

OLE's not dead yet ... but we can only hope.

Steve

No M5a?

2007-02-12T08:40:00.000-05:00

What on earth happened? Traditionally, Eclipse M5 represents a low point in the Eclipse development cycle. If you saw Erich Gamma and John Wiegand's great JavaOne talk last year, it is the lowest dip in the rope. Teams scramble to get features in and stability suffers, causing us to blow the milestone. I know 'cause I've blown a few.

This is normal for the Eclipse development cycle. Does this mean that the dreaded "a" is still to come?

Steve

Get the engineers together and get out of the way!

2007-02-05T08:27:00.000-05:00

Those of you that know me know I avoid calls. I can always be reached through email, the bug system, the newsgroups and mailing lists.

Sometimes, there's a critical situation and a call is dictated. Normally this consists of twelve or more people, only two of which know what is going on. Because nobody can see anyone else, people repeat themselves and state the obvious. There's no eye contact to tell you, "Yes, I understand. I get it."

My reaction to all this is, "My smart people will talk to your smart people. Together they will either fix it, determine that it can never be fixed, or get an estimate of how long it will take to be fixed."

Get the engineers together and get out of the way! Is your manager listening?

Steve

Vista Ships: "Show us your Wow"

2007-01-30T07:35:00.000-05:00

Hello, I'm a Mac ... and I'm a PC.

PC, why do you look just like me? Well, rather than using the processor to do real work, like copying your files or searching your hard disk, I think it's important to show you pictures of puppies.

That's just so cool . Wait until I can put my windows in a blender, just like you (you'll need a hardware upgrade for that).

Microsoft, I'd show you my "Wow", but I might get arrested.

Steve

Best compile error ever!

2007-01-07T09:29:00.000-05:00

Here is a boring line of C code:

createJavaVM = findSymbol(jniLibrary, _T_ECLIPSE("JNI_CreateJavaVM"));

On a C compiler that shall remain nameless, forgetting to cast the result (using (JNI_createJavaVM)) gives the following:

"../eclipseJNI.c", line 193: warning: assignment type mismatch:
pointer to function(pointer to pointer to pointer to const struct JNIInvokeInterface_ {pointer to void reserved0, pointer to void reserved1, pointer to void reserved2, pointer to function(..) returning int DestroyJavaVM, pointer to function(..) returning int AttachCurrentThread, pointer to function(..) returning int DetachCurrentThread, pointer to function(..) returning int GetEnv, pointer to function(..) returning int AttachCurrentThreadAsDaemon}, pointer to pointer to pointer to const struct JNINativeInterface_ {pointer to void reserved0, pointer to void reserved1, pointer to void reserved2, pointer to void reserved3, pointer to function(..) returning int GetVersion, pointer to function(..) returning pointer to struct _jobject {..} DefineClass, pointer to function(..) returning pointer to struct _jobject {..} FindClass, pointer to function(..) returning pointer to struct _jmethodID {..} FromReflectedMethod, pointer to function(..) returning pointer to struct _jfieldID {..} FromReflectedField, pointer to function(..) returning pointer to struct _jobject {..} ToReflectedMethod, pointer to function(..) returning pointer to struct _jobject {..} GetSuperclass, pointer to function(..) returning unsigned char IsAssignableFrom, pointer to function(..) returning pointer to struct _jobject {..} ToReflectedField, pointer to function(..) returning int Throw, pointer to function(..) returning int ThrowNew, pointer to function(..) returning pointer to struct _jobject {..} ExceptionOccurred, pointer to function(..) returning void ExceptionDescribe, pointer to function(..) returning void ExceptionClear, pointer to function(..) returning void FatalError, pointer to function(..) returning int PushLocalFrame, pointer to function(..) returning pointer to struct _jobject {..} PopLocalFrame, pointer to function(..) returning pointer to struct _jobject {..} NewGlobalRef, pointer to function(..) returning void DeleteGlobalRef, pointer to function(..) returning void DeleteLocalRef, pointer to function(..) returning unsigned char IsSameObject, pointer to function(..) returning pointer to struct _jobject {..} NewLocalRef, pointer to function(..) returning int EnsureLocalCapacity, pointer to function(..) returning pointer to struct _jobject {..} AllocObject, pointer to function(..) returning pointer to struct _jobject {..} NewObject, pointer to function(..) returning pointer to struct _jobject {..} NewObjectV, pointer to function(..) returning pointer to struct _jobject {..} NewObjectA, pointer to function(..) returning pointer to struct _jobject {..} GetObjectClass, pointer to function(..) returning unsigned char IsInstanceOf, pointer to function(..) returning pointer to struct _jmethodID {..} GetMethodID, pointer to function(..) returning pointer to struct _jobject {..} CallObjectMethod, pointer to function(..) returning pointer to struct _jobject {..} CallObjectMethodV, pointer to function(..) returning pointer to struct _jobject {..} CallObjectMethodA, pointer to function(..) returning unsigned char CallBooleanMethod, pointer to function(..) returning unsigned char CallBooleanMethodV, pointer to function(..) returning unsigned char CallBooleanMethodA, pointer to function(..) returning signed char CallByteMethod, pointer to function(..) returning signed char CallByteMethodV, pointer to function(..) returning signed char CallByteMethodA, pointer to function(..) returning unsigned short CallCharMethod, pointer to function(..) returning unsigned short CallCharMethodV, pointer to function(..) returning unsigned short CallCharMethodA, pointer to function(..) returning short CallShortMethod, pointer to function(..) returning short CallShortMethodV, pointer to function(..) returning short CallShortMethodA, pointer to function(..) returning int CallIntMethod, pointer to function(..) returning int CallIntMethodV, pointer to function(..) returning int CallIntMethodA, pointer to function(..) returning long long CallLongMethod, pointer to function(..) returning long long CallLongMethodV, pointer to function(..) returning long long CallLongMethodA, pointer to function(..) returning float CallFloatMethod, pointer to function(..) returning float CallFloatMethodV, pointer to function(..) returning float CallFloatMethodA, pointer to function(..) returning double CallDoubleMethod, pointer to function(..) returning double CallDoubleMethodV, pointer to function(..) returning double CallDoubleMethodA, pointer to function(..) returning void CallVoidMethod, pointer to function(..) returning void CallVoidMethodV, pointer to function(..) returning void CallVoidMethodA, pointer to function(..) returning pointer to struct _jobject {..} CallNonvirtualObjectMethod, pointer to function(..) returning pointer to struct _jobject {..} CallNonvirtualObjectMethodV, pointer to function(..) returning pointer to struct _jobject {..} CallNonvirtualObjectMethodA, pointer to function(..) returning unsigned char CallNonvirtualBooleanMethod, pointer to function(..) returning unsigned char CallNonvirtualBooleanMethodV, pointer to function(..) returning unsigned char CallNonvirtualBooleanMethodA, pointer to function(..) returning signed char CallNonvirtualByteMethod, pointer to function(..) returning signed char CallNonvirtualByteMethodV, pointer to function(..) returning signed char CallNonvirtualByteMethodA, pointer to function(..) returning unsigned short CallNonvirtualCharMethod, pointer to function(..) returning unsigned short CallNonvirtualCharMethodV, pointer to function(..) returning unsigned short CallNonvirtualCharMethodA, pointer to function(..) returning short CallNonvirtualShortMethod, pointer to function(..) returning short CallNonvirtualShortMethodV, pointer to function(..) returning short CallNonvirtualShortMethodA, pointer to function(..) returning int CallNonvirtualIntMethod, pointer to function(..) returning int CallNonvirtualIntMethodV, pointer to function(..) returning int CallNonvirtualIntMethodA, pointer to function(..) returning long long CallNonvirtualLongMethod, pointer to function(..) returning long long CallNonvirtualLongMethodV, pointer to function(..) returning long long CallNonvirtualLongMethodA, pointer to function(..) returning float CallNonvirtualFloatMethod, pointer to function(..) returning float CallNonvirtualFloatMethodV, pointer to function(..) returning float CallNonvirtualFloatMethodA, pointer to function(..) returning double CallNonvirtualDoubleMethod, pointer to function(..) returning double CallNonvirtualDoubleMethodV, pointer to function(..) returning double CallNonvirtualDoubleMethodA, pointer to function(..) returning void CallNonvirtualVoidMethod, pointer to function(..) returning void CallNonvirtualVoidMethodV, pointer to function(..) returning void CallNonvirtualVoidMethodA, pointer to function(..) returning pointer to struct _jfieldID {..} GetFieldID, pointer to function(..) returning pointer to struct _jobject {..} GetObjectField, pointer to function(..) returning unsigned char GetBooleanField, pointer to function(..) returning signed char GetByteField, pointer to function(..) returning unsigned short GetCharField, pointer to function(..) returning short GetShortField, pointer to function(..) returning int GetIntField, pointer to function(..) returning long long GetLongField, pointer to function(..) returning float GetFloatField, pointer to function(..) returning double GetDoubleField, pointer to function(..) returning void SetObjectField, pointer to function(..) returning void SetBooleanField, pointer to function(..) returning void SetByteField, pointer to function(..) returning void SetCharField, pointer to function(..) returning void SetShortField, pointer to function(..) returning void SetIntField, pointer to function(..) returning void SetLongField, pointer to function(..) returning void SetFloatField, pointer to function(..) returning void SetDoubleField, pointer to function(..) returning pointer to struct _jmethodID {..} GetStaticMethodID, pointer to function(..) returning pointer to struct _jobject {..} CallStaticObjectMethod, pointer to function(..) returning pointer to struct _jobject {..} CallStaticObjectMethodV, pointer to function(..) returning pointer to struct _jobject {..} CallStaticObjectMethodA, pointer to function(..) returning unsigned char CallStaticBooleanMethod, pointer to function(..) returning unsigned char CallStaticBooleanMethodV, pointer to function(..) returning unsigned char CallStaticBooleanMethodA, pointer to function(..) returning signed char CallStaticByteMethod, pointer to function(..) returning signed char CallStaticByteMethodV, pointer to function(..) returning signed char CallStaticByteMethodA, pointer to function(..) returning unsigned short CallStaticCharMethod, pointer to function(..) returning unsigned short CallStaticCharMethodV, pointer to function(..) returning unsigned short CallStaticCharMethodA, pointer to function(..) returning short CallStaticShortMethod, pointer to function(..) returning short CallStaticShortMethodV, pointer to function(..) returning short CallStaticShortMethodA, pointer to function(..) returning int CallStaticIntMethod, pointer to function(..) returning int CallStaticIntMethodV, pointer to function(..) returning int CallStaticIntMethodA, pointer to function(..) returning long long CallStaticLongMethod, pointer to function(..) returning long long CallStaticLongMethodV, pointer to function(..) returning long long CallStaticLongMethodA, pointer to function(..) returning float CallStaticFloatMethod, pointer to function(..) returning float CallStaticFloatMethodV, pointer to function(..) returning float CallStaticFloatMethodA, pointer to function(..) returning double CallStaticDoubleMethod, pointer to function(..) returning double CallStaticDoubleMethodV, pointer to function(..) returning double CallStaticDoubleMethodA, pointer to function(..) returning void CallStaticVoidMethod, pointer to function(..) returning void CallStaticVoidMethodV, pointer to function(..) returning void CallStaticVoidMethodA, pointer to function(..) returning pointer to struct _jfieldID {..} GetStaticFieldID, pointer to function(..) returning pointer to struct _jobject {..} GetStaticObjectField, pointer to function(..) returning unsigned char GetStaticBooleanField, pointer to function(..) returning signed char GetStaticByteField, pointer to function(..) returning unsigned short GetStaticCharField, pointer to function(..) returning short GetStaticShortField, pointer to function(..) returning int GetStaticIntField, pointer to function(..) returning long long GetStaticLongField, pointer to function(..) returning float GetStaticFloatField, pointer to function(..) returning double GetStaticDoubleField, pointer to function(..) returning void SetStaticObjectField, pointer to function(..) returning void SetStaticBooleanField, pointer to function(..) returning void SetStaticByteField, pointer to function(..) returning void SetStaticCharField, pointer to function(..) returning void SetStaticShortField, pointer to function(..) returning void SetStaticIntField, pointer to function(..) returning void SetStaticLongField, pointer to function(..) returning void SetStaticFloatField, pointer to function(..) returning void SetStaticDoubleField, pointer to function(..) returning pointer to struct _jobject {..} NewString, pointer to function(..) returning int GetStringLength, pointer to function(..) returning pointer to const unsigned short GetStringChars, pointer to function(..) returning void ReleaseStringChars, pointer to function(..) returning pointer to struct _jobject {..} NewStringUTF, pointer to function(..) returning int GetStringUTFLength, pointer to function(..) returning pointer to const char GetStringUTFChars, pointer to function(..) returning void ReleaseStringUTFChars, pointer to function(..) returning int GetArrayLength, pointer to function(..) returning pointer to struct _jobject {..} NewObjectArray, pointer to function(..) returning pointer to struct _jobject {..} GetObjectArrayElement, pointer to function(..) returning void SetObjectArrayElement, pointer to function(..) returning pointer to struct _jobject {..} NewBooleanArray, pointer to function(..) returning pointer to struct _jobject {..} NewByteArray, pointer to function(..) returning pointer to struct _jobject {..} NewCharArray, pointer to function(..) returning pointer to struct _jobject {..} NewShortArray, pointer to function(..) returning pointer to struct _jobject {..} NewIntArray, pointer to function(..) returning pointer to struct _jobject {..} NewLongArray, pointer to function(..) returning pointer to struct _jobject {..} NewFloatArray, pointer to function(..) returning pointer to struct _jobject {..} NewDoubleArray, pointer to function(..) returning pointer to unsigned char GetBooleanArrayElements, pointer to function(..) returning pointer to signed char GetByteArrayElements, pointer to function(..) returning pointer to unsigned short GetCharArrayElements, pointer to function(..) returning pointer to short GetShortArrayElements, pointer to function(..) returning pointer to int GetIntArrayElements, pointer to function(..) returning pointer to long long GetLongArrayElements, pointer to function(..) returning pointer to float GetFloatArrayElements, pointer to function(..) returning pointer to double GetDoubleArrayElements, pointer to function(..) returning void ReleaseBooleanArrayElements, pointer to function(..) returning void ReleaseByteArrayElements, pointer to function(..) returning void ReleaseCharArrayElements, pointer to function(..) returning void ReleaseShortArrayElements, pointer to function(..) returning void ReleaseIntArrayElements, pointer to function(..) returning void ReleaseLongArrayElements, pointer to function(..) returning void ReleaseFloatArrayElements, pointer to function(..) returning void ReleaseDoubleArrayElements, pointer to function(..) returning void GetBooleanArrayRegion, pointer to function(..) returning void GetByteArrayRegion, pointer to function(..) returning void GetCharArrayRegion, pointer to function(..) returning void GetShortArrayRegion, pointer to function(..) returning void GetIntArrayRegion, pointer to function(..) returning void GetLongArrayRegion, pointer to function(..) returning void GetFloatArrayRegion, pointer to function(..) returning void GetDoubleArrayRegion, pointer to function(..) returning void SetBooleanArrayRegion, pointer to function(..) returning void SetByteArrayRegion, pointer to function(..) returning void SetCharArrayRegion, pointer to function(..) returning void SetShortArrayRegion, pointer to function(..) returning void SetIntArrayRegion, pointer to function(..) returning void SetLongArrayRegion, pointer to function(..) returning void SetFloatArrayRegion, pointer to function(..) returning void SetDoubleArrayRegion, pointer to function(..) returning int RegisterNatives, pointer to function(..) returning int UnregisterNatives, pointer to function(..) returning int MonitorEnter, pointer to function(..) returning int MonitorExit, pointer to function(..) returning int GetJavaVM, pointer to function(..) returning void GetStringRegion, pointer to function(..) returning void GetStringUTFRegion, pointer to function(..) returning pointer to void GetPrimitiveArrayCritical, pointer to function(..) returning void ReleasePrimitiveArrayCritical, pointer to function(..) returning pointer to const unsigned short GetStringCritical, pointer to function(..) returning void ReleaseStringCritical, pointer to function(..) returning pointer to struct _jobject {..} NewWeakGlobalRef, pointer to function(..) returning void DeleteWeakGlobalRef, pointer to function(..) returning unsigned char ExceptionCheck, pointer to function(..) returning pointer to struct _jobject {..} NewDirectByteBuffer, pointer to function(..) returning pointer to void GetDirectBufferAddress, pointer to function(..) returning long long GetDirectBufferCapacity}, pointer to void) returning int "=" pointer to void

That was easy to figure out, wasn't it?

Steve

I am Eclipse

2006-12-18T21:02:00.000-05:00

The other day, I found out I was Eclipse. Apparently, Eclipse is a grizzled old platform hacker, whose every second word is f*ck ...

Seriously, I can see both sides of the "Eclipse is You" thing. Sometimes, people just complain and don't help (sometimes they are paid to do this but that's another story). Those must be the people Ward is talking about. Other people submit really good patches and we run out of time to process them. Often in SWT land, patches contain the essence of a fix or feature, but the real implementation is much more work. One thing that people don't seem to understand is that once an API is in, it can never come out. It must be supported forever. That's a long time (and a lot of work).

Anyhow, please hang in there and ping those bug reports that contain patches.

Steve

Apocalypto

2006-12-12T23:00:00.000-05:00

Watch for a surprise appearance by the Blue Man Group in Mel Gibson's newest blockbuster!

Steve

Big news!

2006-12-11T10:13:00.000-05:00

There's been some negativity lately on EclipseZone (shame on you) and elsewhere about Eclipse, the number one, kick-ass, couldn't-live-without, Java IDE desert topping and floor wax. Why?

Big News: Google joined Eclipse. I know some of those guys. They are smart. They hacked their way through SWT, OLE, the browser, submitted patches and found bugs. That's big news for me.

Bigger news: A Brazilian joined NetBeans. Not such big news for me, I already have two.

My advice: Don't drink the kool aid! There's stuff in there that's bad for you.

Steve

The smart bit

2006-11-06T16:45:00.000-05:00

After lots of thought, discussion and hard work, I am pleased and proud to finally announce: the SWT smart bit. Somehow, this new and exciting feature got left out of the Eclipse 3.3 M3 "New and Not-worthy". Here it is:

public static int SMART = 0;

Why settle for a dumb version of that old text control when you can spice it up with the smart bit:

new Text (parent, SWT.BORDER | SWT.SMART);

Even better, it works everywhere. Given a choice between two components, wouldn't you always take the smart one?

Swteve

Windows 64-bit

2006-10-16T16:57:00.000-05:00

I'm currently working with Grant Gayed, porting SWT to Windows 64. Some smart guys from Intel submitted a great patch (57151). However, each line of code needs to be painfully checked. Why?

"Every line is sacred, every line is great ..."

Ok, the real reason: it's easy to make subtle mistakes and cause GP's. We found only a few so far (because those guys did such a great job). Anyway, during our travels, we got to see the Windows API again and I forgot how funny some of it was. Here are a few things we ran across:

#define TECHNOLOGY 2 // bet you didn't know that!

typedef enum tagFUNCKIND {
FUNC_VIRTUAL,
FUNC_PUREVIRTUAL,
FUNC_NONVIRTUAL,
FUNC_STATIC,
FUNC_DISPATCH,
} FUNCKIND // FUNCKIND kids these days!

BOOL InitCommonControlsEx(
const LPINITCOMMONCONTROLSEX lpInitCtrls
); // Horny little devils

STGC_DANGEROUSLYCOMMITMERELYTODISKCACHE = 4
// What the ?!?!

Steve

How many times have you done this?

2006-09-25T17:43:00.000-05:00

You've got a problem to solve. It's really complicated. Rather than attempt the final solution, you hack and slash a way through it. The code you wrote is not real. It is total garbage. It proves that the problem can be solved, but you could never ship like that.

What now? Time to step back, write the general solution, rework everything, fix the corner cases, check for error conditions, change all places that do it the old way to do it the new way, check for leaks and clean up the code. Now you are done and ... nothing works.

By this time, you've blown away the old code so you have no idea what the problem is. Did it ever work at all? What did I change? Was I doing a Billy?

Steve

Alphabet soup

2006-09-18T12:13:00.000-05:00

The other day I had to make a presentation and started listing the various different technologies that we support. Here are some of them:

Win32, GDI, GDI+, OLE, IE, Carbon, Cocoa, Core Graphics, Quick Draw, Safari, ATSUI, X Windows, X/t, Motif, GTK, GDK, Pango, cairo, ATK, Photon, Mozilla, QNX Voyager, Uniscribe and I almost forgot AWT/Swing.

What's the message? Forget about technology wars. Go forth and build something!

Steve

ayahuasca

2006-09-11T09:52:00.000-05:00

Have you heard of this stuff? It's a brew made out of vines and leaves from the Amazon rain forest. It causes blinding, vivid, hyper-real hallucinations. It's so strong that people who take it sometimes wear Depends because they shit themselves and/or vomit uncontrollably. Mmmm ... gimme some of that!

What does this have to do with software? I was wondering whether ayahuasca might help me debug a problem I was having with SWT on Vista. As you may not know, multi-select trees are not supported natively on Windows. We emulate them using the wad of code pattern on top of the native tree. It seems that Microsoft finally got around to trying to implement multi-selection, but bailed at the last minute (see TVS_EX_MULTISELECT). My guess is that some of that code still remains in Vista.

Anyway, the bug was that when you selected the nth item, the n-2th selected item was deselected for free (NOTE: not the n-1th). Ok, I'm easy. I went and happily remembered the n-2th item and reselected it. Then, Vista started deselecting the n-3rd item. The chase was on! No matter how many I remembered and reselected, Vista deselected one more. Then I took the ayahuasca.

The fix came in a blinding flash!

Steve

Code Ownership

2006-08-28T08:52:00.000-05:00

I can't praise code ownership enough. Do you know some code that is unowned? If so, I bet you also know code that is unloved. What sorts of benefits does code ownership bring?

Owning code promotes pride and responsibility. Owning code, especially over a long period of time, allows us to become known for quality work. Even more important, we get to see the results of both good and bad design decisions. From mistakes, we improve our skills.

If you flop around from project to project, submit code and never maintain it, you'll never get to see any of this. You'll think you're a better programmer than you are.

Steve

SWT Speak (Part 2)

2006-08-21T22:26:00.000-05:00

Here are some more SWT technical terms for you. Use them and abuse them!

cake - code that is unnecessarily complex, multi-layered, and full of indirection. "The cake clouds everything. Impossible to see the code is."

pinhead - a very small widget. "Where is the stupid thing? Oh, it's a pinhead."

fly shit - small graphical output. "Of course you can't read it, you chose the fly shit font!"

Steve

SWT Speak (Part 1)

2006-08-14T19:25:00.000-05:00

There are lots of technical terms the SWT committers use without thinking, assuming that the rest of the world understands. So, if you enter a bug report against Platform SWT, you're cool if you use any of these:

cheese - pixel corruption. "I just clicked and look, cheese everywhere, all over the screen!"

new and improved - a bug was introduced. "The extra mouse up event is new and improved for 3.2."

spew - debugging messages to a console. "Run the example, observe all the GTK spew when you click on the button. Yikes!"

wad - lots of code. "Just cut, paste and exec the wad."

Steve

Hello from WWDC!

2006-08-07T09:31:00.000-05:00

I'm here at WWDC (Apple's World Wide Developer Conference) in California. Right now, I'm listening to Steve Jobs and he's not jumping around the room screaming, "Developers, developers, developers ...". Instead, we're seeing great demos. As I look around, I see true believers. Heck, if you cut these guys, they'd bleed rainbow.

The more I think about it, the more I come to the conclusion that Apple has worked hard to embrace Java. They ship Java as part of their operating system. No need to ask users to download a JVM or ship one with your product. Microsoft doesn't ship Java (they used to but they got sued -- now we have C#). Linux distributions don't ship Java (the licensing is wrong but Sun is fixing this).

Apple worked hard from the start to let people build real Java applications. They are the only guys I know who let you easily create double clickable applications that have the right icons and start just like native ones. They fixed Swing way back when to have the Macintosh look and feel. They run a version of the JVM that does the MVM (multiple virtual machine) thing that shares class files between processes and cuts down on memory usage.

Thanks guys for all the hard work!

Steve

We just keep fixin' em

2006-08-02T09:21:00.000-05:00

The SWT committers just keep hammering away, making things better. Lots of major bugs are getting fixed and new features implemented, but no one makes a fuss. Code speaks louder than words, right? Let the "New and Noteworthy" do the talking. That's the SWT motto. Why do I have this blog then?

Some say a BLOG is a ...

B - loated
L - ying
O - verblown
G - lorification

Yikes! I feel "New and Not Worthy". Time to stop typing and go fix something. How about 138528?

Steve

Kids these days

2006-07-31T09:55:00.000-05:00

The last conference I was at, I went to dinner with a professor from a well known university. Ever known someone who just wants to argue with you and make his point, no matter what you say? This guy was a macro expansion. I said one word and he expanded!

Anyways, this guy began frothing at the mouth when I suggested that learning Lisp, Prolog, Smalltalk and other computer languages was good for the students. Don't get me wrong, I wasn't suggesting that they dump C, HTML and Java (or whatever else will get you a job these days). My point was that these sorts of languages contain different concepts that open up your mind to new ideas and new ways of thinking. If you don't see these things in school, then where else will you see them? You are in danger of never learning what a closure is (Java sure don't have 'em) or really understanding recursion or backtracking. Where better to learn than in school, where you don't need to ship and bugs don't cost people money?

Alas, I failed. Kids these days are missing out. Sad but true.

Steve

"I just click around all day ..."

2006-07-26T10:49:00.000-05:00

Fixing bug 125656 was a real challenge. You can go read the bug report, but the summary is that a certain combination of hover help windows and clicking caused the operating system (MacOS X 10.4) to lose track of top level shells, making them dead to mouse clicks. This problem was particularly hard to find because it was intermittent. Attempts to construct a simple case outside of Eclipse failed.

So how did we fix it? First of all, we investigate the obvious. Is the shell somehow disabled? Are the mouse events going somewhere else? Is there a mouse grab stuck? Is the shell somehow disposed but still drawing? Then we discovered that FindWindow, the MacOS X carbon call that is used to locate a window given a point on the screen, couldn't find our window. Calls to IsValidWindowPtr showed that the window was still alive. What could possibly be the problem?

To find out, we wrote a method that traversed the operating system window list and soon noticed that there were shells in SWT data structures that were not in the list. We called the method after every event was dispatched and traced all the operating system calls to find out when the bad thing happened. We did all this in Java, not C, which is one of the great things about SWT. No custom C code.

I almost forgot. When a problem is intermittent, you can't ever really know for sure that it's fixed. You have to rely on statistics. So Silenio spent two days on and off, narrowing down the mouse clicks until he could get the problem to happen within 5 minutes. During that time, I asked him what he was doing and he said, "I just click around all day ..."

Steve

Closing 37683

2006-07-23T10:35:00.000-05:00

We closed 37683. At times, this bug resembled a blog rather than a bug report. It was used by some to spread FUDge about the toolkit and that's bad. Fortunately, I don't have a sweet tooth.

Let's be clear. Some people were seeing problems and we worked hard to isolate them (the problems - not the people). When there was a bug we could recreate, we opened a new bug report and fixed it. We wrote example code that created the same window using GTK calls in C, then GTK calls in Java and finally in pure SWT code to see whether there were fundamental problems in the event loop or elsewhere in the toolkit. There weren't.

Some of the focus was on the speed of popup menus. Menus come up fast in SWT, but application programs like Eclipse do lots of domain specific work to enable or disable items and in some cases, build a new menu each time a menu is requested. If this work involves file i/o and threads, then performance numbers are variable.

Was this bug worth it? I'd have to say "yes". We found and fixed real problems and that makes me happy.

Steve

Code == crap

2006-07-08T16:14:00.000-05:00

Back in university, there were two kinds of students. For arguments sake, let's call them the cleans and the scruffs. The cleans were smart guys, interested in algorithms, computability and understanding that work could be done. The scruffs were smart too. They studied and understood the same sorts of things, but in the end, they just got in there and made things go. I'm a scruff.

As a scruff, I've come to the conclusion that code is crap. I hate code. Any code. Mine too. Code is slow. Code has bugs. Given two solutions to a problem, I'll pick the one with the fewest number of lines.

As a community in the broadest sense of the word (Microsoft included), we design these monstrous layered architectures, then wonder why our systems are slow. Want to know how to make something faster? Run less code. Do you care how a library is implemented? You shouldn't. Want me to write a bunch of code in the name of truth and beauty? I won't.

Ok, I'm a closet clean but don't tell anyone ... I like binary search.

Steve

How does anything work?

2006-07-05T21:56:00.000-05:00

When I think about all the places SWT runs and the things we do to make it work, it blows my mind.

Windows flavours include Windows 98, CE, NT, 2000, ME, XP and soon Vista. The win32 API has two identical calls for everything, one for ANSI and one for Unicode. Windows 98 and ME support only ANSI, while CE supports only Unicode. Windows NT, 2000, XP and Vista support both. This means no single API is available on all Windows platforms. C programs are supposed to compile for one or the other. Instead, we build one set of jars and native libraries for both and call the right API on the fly. It's ugly, but it works.

GTK is version hell. We run all the way back to 2.0.6. Lots of new API has been added since then so we look them up dynamically because Linux won't load a shared library with unsatisfied references. Somehow, when an operating system API isn't there, we run alternate code or fail gracefully. Whew!

Mozilla is it's own nightmare. Until recently, rather than using the Mozilla that you had installed on your machine, Mozilla.org expected you to ship a copy of Mozilla statically linked to your application. Somehow we don't do this, find the installed Mozilla and use it. We work with Mozilla versions as old as 1.2 all the way up to 1.8, which was the latest at the time this article was written. The Linux C++ binary format changed somewhere along the way, breaking us. We detect the right version dynamically and load the one of two identical libraries, compiled differently. Wow.

Advanced graphics on Linux uses the cairo graphics library but this doesn't ship with the current Linux distributions, so we compile and ship our own, just in case. On the fly, we detect whether you already have cairo installed and use that one. Otherwise, we use the one we compiled. It's magic.

The Macintosh comes with two complete and separate native toolkits, carbon and cocoa. We use carbon, the C based API. However, new features in the operating system are very often only available in cocoa. Cocoa is Objective C, not C. Safari, the Mac browser, is written in cocoa. So we call it, leading to wild clipping problems and all sorts of amazing interop issues that we work around. Did I mention that Macintosh controls didn't clip against each other until a few years ago so we had to roll our own sibling and parent clipping code?

AWT is a free threaded widget toolkit that comes with it's own event loop. On Windows, we hook into the event queue and cross post keystrokes. On Motif and GTK, life is easier, we implement the XEmbed protocol, which is a bunch of low level X windows calls. On the Mac, after being broken for ages, we got help from Apple. The Mac operating system has no concept of multiple event loops. Somehow, Apple found a way to make it work. The icing on the cake is that AWT is implemented in cocoa, not carbon.

On the Java side, we need 1.2 VM's or greater and run on J2SE and J2ME. If you recompile the native libraries, we'll run on 1.1.8.

My gawd.

Steve

Printing on GTK

2006-06-28T10:47:00.000-05:00

For the longest time, printing was not supported in GTK. That's bad. Heck, even Motif applications can print and they've been doing it since the beginning of time. Now, thanks to the magic of cairo, GTK applications can print too and so can SWT ... we just need to write the code.

CAR is off hacking this up right now with SSQ and FH. In fact, something was just printed, but the font is small like fly shit.

Steve

Conspiracies? What rubish!

2006-06-24T13:45:00.000-05:00

I've worked in software for a long time. In the early days, I thought that "software was out to get me". Those guys at Microsoft were evil, making API's impossible to use on purpose, just to make my life hard. Technologies were out to kill other technologies and put people out of work. Companies didn't ship features on time because other companies needed them. Not true!

Ok, sometimes this is true, but it's the exception, rather than the rule. I know, because some people think I'm part of a conspiracy and I'm not!

Here are some popular Eclipse ones:

The name "Eclipse" was chosen to offend Sun. That's false. I was there. It was the age of e-everything and someone said "e-clipse". The name stuck.

SWT is out to get Swing. That's false. SWT is native and Swing isn't. If you believe that native is critical, then Java is a non-starter for you without SWT. It's about bringing more people to the Java platform by embracing technology, not starting flame wars.

Eclipse.org is controlled by IBM. Not true. The foundation is completely independent. When it first started, my CVS connection got slower! Seriously, IBM has one vote and no special status in the charter. Go ahead and search it for the string "IBM".

Steve

"I pulled a Billy ..."

2006-06-21T21:28:00.000-05:00

Any of you fortunate enough to know Billy Biggs, know that there is only one word to describe him. That word is awesome. He's a fantastic programmer, cares about your problem, knows everything about everything and even better, knows the guys who can get you the answer. However, as you might have already guessed, he has one particular disturbing flaw.

Ever debug something for hours, only to find out that your test case was wrong and it was working all along? Ever write a piece of code, test it, find a bug, change it, test again, change it, and so on, only to find out that some hack of yours elsewhere in the code meant that you were testing nothing? Ever come to the conclusion that all those assumptions that you were making for the past two hours were completely wrong? If this happens to you, then you pulled a "Billy".

The longest Billy on record: 2 days (but not pulled by the man himself).

I asked him if he cared that we call this a Billy and he said, "Naw, I just want to be famous". Well, you are. The legend lives on.

Steve

@deprecated is a lie

2006-06-19T09:14:00.000-05:00

API is serious business. If you don't need to build reusable libraries, your life is easy. Refactoring tools will help you grow your code for the future. If you build in-house libraries and have only a few well known clients, your clients will hate you, but you can still make changes. For reusable public libraries such as SWT, nothing can change. Ever.

To really understand this, I think you need to have been burned by it at least once. Fortunately for me, this happened early in my career, in a different language and on a different project. I learned my lesson.

You can tell when API failure occurs. A quick search for @deprecated is all it takes. Some people think nothing of leaving a trail of dead API behind them, @deprecating all the way. "We'll just deprecate that" they say, like it fixes everything.

What's wrong with this thinking? For one, API never goes away. It still needs to be tested, debugged and maintained. It takes up space in memory and on disk. But there is a deeper cost. Clients have invested their time and energy learning your API and now you tell them, "Throw that away and start again, it's better this time".

Here is my rule of thumb: If there is any way, I mean any way, to keep an API going, then I'll do it.

We've done a good job of API in SWT over the years and I'm proud of it. SWT is particularly hard because the underlying platforms are so different. One false step leads to disaster. In SWT terms, this is an API where a native implementation is impossible. If you search the source of SWT 3.2 for @deprecated, you'll find only 39 matches in the entire toolkit. Some of these are duplicates because the Javadoc is copied onto all the different platforms. The actual number is 19.

Someday, I'll talk about a few of the things we do to keep it this way.

Steve

"Eclipse is not crap ..."

2006-06-14T11:55:00.000-05:00

The other day, I was out somewhere and a guy found out that I was Mr. SWT and started haranguing me, saying "Eclipse is crap". Usually, I don't bother with this sort of thing. For one thing, who cares? Also, SWT is my baby, not Eclipse. Anyhow, the guy expected me to start bashing him, his company, his product or at least quote a few statistics. Then we could argue over those! Pointless, pointless, pointless.

But then it occurred to me, "Eclipse is not crap ... and I can prove it". Here goes, "SWT is a large pile of Java and C code, build scripts, directories and other random artifacts. It's complicated and runs on five different platforms. I use Eclipse exclusively to develop and maintain it and Eclipse works well. Therefore, it cannot be crap".

Steve

We care ...

2006-06-10T09:07:00.000-05:00

One of the things that's great about open source is the interaction that you have with the community. I've worked on both closed and open source systems and let me tell you, open source is just way more fun. There is no substitute for the level of interaction, quick turn around and raw power in working this way. Give me a guy ranting at me over some processed, filtered and predigested bug list any day!

We helped this guy out yesterday with a bizarre problem that didn't happen on my machine. This bug report resembles a blog with people who hate my guts. Interesting, that all we are doing is writing code, solving problems and trying to ship, just like everyone else. But hey, all it takes is one comment like this to make it all worthwhile.

Steve

Inside SWT

Flogging my FrankenMac

JavaOne

Joining Oracle

After the break up ...

More from the archives

Artifacts from Steve's Office

Message from your Emperor - PLEASE READ - ACTION REQUIRED

You heard Ian!

Eclipse on Cocoa now full of sheet!

Lots of good stuff at EclipseCon

Fighting the Cocoa default button!

Goodbye **early access** for Mac cocoa

Too many meetings ...

Smog Computing

You gotta love the Mac!

The GUI world is a mess

Back to work!

I have a theory ...

Fix only the one place

Schindl's list

The fake Steve Northover

Exciting news!

I'm speaking at e4Con

My talk was accepted

Insights and insults from GTK ...

Assmetrics

Ok community, blow your brains out

Great-a-success!

Hacking at Apple

If I read this one more time, I will puke ...

Lots of gradients, less functionality

Armillaria Ostoyae

Backpfeifengesicht

API grows like fungus!

It just works

Analysis Paralysis

I hate Windows

Is that new IDE feature worthwhile?

Announcing Avaj!

No code nirvana

Insights from the Xlib Programming Manual

BYTE Magazine, January 1997: "Can Java Replace Windows?"

Useless dialog of the day

This blog has been accused of having no content

The software Gods and the global cache

Refuctoring your code

It's the end of an era

What happens when you don't fix a critical bug?

No M5a?

Get the engineers together and get out of the way!

Vista Ships: "Show us your Wow"

Best compile error ever!

I am Eclipse

Apocalypto

Big news!

The smart bit

Windows 64-bit

How many times have you done this?

Alphabet soup

ayahuasca

Code Ownership

SWT Speak (Part 2)

SWT Speak (Part 1)

Hello from WWDC!

We just keep fixin' em

Kids these days

"I just click around all day ..."

Closing 37683

Code == crap

How does anything work?

Printing on GTK

Conspiracies? What rubish!

"I pulled a Billy ..."

@deprecated is a lie

"Eclipse is not crap ..."

We care ...

Goodbye early access for Mac cocoa