The first milestone of the e4 project has been released. There’s lots of cool stuff in there for you to check out, here is just a smattering:

• Modeled UI:  The goal of this work is to make it easier to contribute parts (views, editors), to allow greater reuse of them in a wider variety of contexts, and to be able to assemble the parts together in new ways, allowing new “shapes” to the workbench (e.g. include or don’t include perspectives).  This will be a boon in particular for RCP developers who want to make something other than an IDE.
• Skinning:  You can now express many visual aspects such as font and color choices in the form of CSS style sheets.  By externalizing these choices, components can be reused and assembled into significantly different looking applications.  I will be writing more on this subject in future posts, including a walk-through on building an RCP application with CSS skinning.
• Contexts, Application Services, and Dependency Injection: One of the barriers to reuse of UI components is direct reference to global workbench. To provide cleaner component boundaries, access to this state in e4 is now via contexts which are injected into the constructors of the parts.  For example, selection change notification outbound from the part is expressed through change of the selection value in the context.  Similarly, workbench services such as progress will be provided via this mechanism.
• SWT/BE:  SWT widgets cross compiled to Flex or Dojo, this is one important reuse element of Eclipse being able to move to the web.  And, the technology is oh so cool.

Check it out, there’s builds, demos to run… it’s looking pretty real!  And of course, get involved!

In my hobby time, I like to make electronic music.  A piece of software I’ve been using for ages now is called Ableton Live.  They’ve just released a new version which integrates Max/MSP/Jitter, which itself is a visual programming environment for making new electronic synths, controlling video via Jitter, … the list goes on.  There’s a highly active open source community of users of Max who exchange Max patches and thus share their home brew synths, interface to a custom music controller, etc.

This integration is extremely cool in ways I can’t get into in this post, but what I thought interesting for this audience was this discussion around open source v.s. commercial software (my bolding):

It’s not such fantastic news for the open source world or competing tools, because this is a very proprietary and vendor-specific solution. That’s not a criticism, just an observation – I know fantastic people and friends who are supported by the business model that’s here. But it is worth noting, because I believe healthy software ecosystems incorporate both free and commercial models, and fully open and fully “integrated” (which are sometimes more closed) solutions.

That said, I think it’s still an opportunity for open source alternatives to differentiate themselves, and for the two to coexist harmoniously.

Sound familiar?  You could take that paragraph and use it to describe Eclipse.

We’ve been saying these words around commercial vs. free (commercial plus free!) from the beginning.  Sometimes people mistakenly believe that open source just means free software.  I’m very proud of Eclipse, and while I take my role in the community quite seriously and really enjoy it, I don’t write free Eclipse software to be nice.  I do it because it helps to build a healthy and dynamic ecosystem whereby everyone can benefit, and to the degree I can be successful at that, my employer can produce value-add commercial products and pay me to do it.  Eveyone wins, but only if everyone provides value in some form (free or not).

The e4 CSS work, which originated from the open source TK-UI project, is now mostly working.  There’s still many methods left to fill in but the common things now work - fonts, colors, images on labels, buttons, text, dropdowns, and some CTabFolder support.  The screen cap below shows an example adpated from the TK-UI code.  It has the nice quality that changes in the style sheet, displayed in the middle, are immediately reflected in the example.

To give it a spin,

• Pick up the 3.4.1 Eclipse SDK (or later).
• Follow the instructions for bringing in from CVS the folder with the project set files.
• In the Package Explorer, select e4.ui.css.psf, popup the menu and select “Import Project Set…”

• Checkout org.eclipse.e4.ui.examples.css

• Select the class CSSEditorSWTWidgets.java and run it.

Play around!

• Try changing the style sheet displayed in the middle.  For example, change the font sizes or font names.
• Try removing the background image for Text and set the text color to red (try “color: red;” or “color: #ff0000;”) and the background-color to yellow (try “background-color: yellow”).
• Try changing the CTabFolder’s font, font size, and color.

For EclipseCon 09 I’m organizing the e4 track.  We have three sessions of short talks, and each needs a curator whose role it is to introduce the speakers, moderate the discussion, etc.  A low cost way to share the luvin’ at the conference is to have community members be the curators.

This being my first year on the program committee, I approached this like you’d approach organizing a party: figure how many people you can hold and invite some factor more, assuming some won’t be able to make it for whatever reasons.

But I underestimated just how darn helpful the Eclipse community is!  With three sessions to fill, last night I sent out five emails and Immediately got a response of yes, then another response of yes waiting in my inbox this morning, both interested in the same session!

Apparently the right approach is to pick specific people for a session, then ask them, assuming that they will say yes, because it’s almost guaranteed that they will.

Doh!  It’s not really cool to be asked to do something, then being told your help isn’t required, so I feel kind of bad.

It has once again reminded me of how incredible this community is.

A little red faced,

Kevin

I’ve heard people talk about test-first programming but in truth I had never really given it a good try. Until now.

Working on the e4 CSS support provided a great opportunity.  As some of you may know, the e4 CSS code was generously contributed from an existing external project.  Unfortunately, some of the IP lineage of the code was tainted with GPL code so some didn’t make it into the Eclipse CVS repository.  This left a number of classes missing in the middle of the contribution.

I knew which classes were missing, including their hierarchies and implements, and I was able to generate the method signatures by either quick fixing calls to missing methods or by gen’ing the required interface methods.  Now to fill in the method bodies.

A perfect opportunity for test-first programming!

I wrote a very basic junit test (create an SWT label, have style sheet set background color, check if that’s the color in the widget). I then went to every method with missing body and wrote:


throw new UnsupportedOperationException("NOT YET IMPLEMENTED");


I picked this because its a runtime exception and thus didn’t require changing method signatures or callers, and because I’d be unlikely to trigger one in some other code.  I then set the Eclipse debugger to breakpoint on all caught and uncaught UnsupportedOperationException’s.

Development proceeded like:

• Run test
• See where it halts
• Write the method
• Rerun, repeat!

It was somewhat reminicient of the “laying the tracks out in front of the train” scene in Wallace and Gromit.

What was curious about this approach was that I was completely surprised (and delighted) when it finally ran green.  I knew I was getting close based on the places where it was stopping, but still didn’t know how close!

I think the key here was that I had such a good specification of the requirements of the code and this could be easily translated into a test.  The test was obvious to write, and the need for a test to guide my coding was also obvious — What else would I do, keep running the same example?  Might as well write it as a test!

For more open ended problems the requirements and code sort of co-evolve.  Maybe in this case test-first does apply as well, or then again maybe you use the tests as the way to express one side of the evolving contract.

In any case, this experience was an excellent example of how valuable an approach it can be.

I’m sure you all suffer from the same problem as I, which is that you can get a heck of a lot of bugzilla email during the course of a day (well, a lot in general, but bugzilla is one I think I can do something about). Not all of it is urgent though. Lately I’ve been finding that my focus and attention is being driven by what comes into my inbox. When that happens, I no longer feel like I’m in control of my day (because, well, I’m not). I’d rather drive what I do based on my priorities, but I still need to maintain some awareness of what’s going on since some issues are timely.

The problem with bugzilla is that you can end up being on a heck of a lot of CC lists. This can be especially true for me when I’ve been doing bug triaging since I tend to CC myself on bugs I’m not sure I’ve vectored correctly. I don’t know about you, but I tend to not remove myself from CC’s even when they no longer serve a purpose.

Sometimes an item will be under heated conversation. For these, my preference is to wait a bit then get caught up with several comments in a row, rather than reading each in turn. I try to do this in recognition of the fact that building up the context in order to understand the latest comment takes time, and I’d like to be more efficient by collating those together.

My current experiment is the following email filter. It’s Lotus Notes, but most modern emailers have similar capabilities. Here I’m attempting to vector all bugzilla email to a dedicated folder which in theory I will check say once a day or every other day (ie. at a time of my chosing, not when the bugs come in). However, I did that in the past and the result was missing out on things people wanted me to comment on. I realized that its not all bugzilla email that should be filtered out, but rather than there is a subset that I want to prioritize my attention to and have in my inbox. The following filter attempts to express this.

Bugs assigned to me, or ones I logged, get priority. and go my inbox.  The interesting one for me is the exception “Body contains ‘Kevin’”, which tries to capture the pattern,

“Kevin, do you agree?” “Kevin, can I take this bug?” “Kevin, are you there?” “Wake up Kevin!”

It’s still early but so far this seems to be helping.

I’m wondering how others deal with the bugzilla tidal wave.

The deadline for proposals for EclipseCon09 is just two weeks away! OK it’s still two whole weeks, so no panic, but since we all know you’re not going to submit anything until the very last minute anyway, now might be a good time to plan on panicking.

Some suggestions, just to get yourself ready:

1. Scream “OMG! OMG! Why did I put this off for so long?!”. Practice on family pet, then try on a loved one.
2. Send out a mad flurry of emails to people who you’ve said, “You know, we should really write a paper on that someday”, asking them if they can remember what the heck exactly “that” was.
3. Open whatever app you like for document writing. Turn on favorite music. Stare at blank page for awhile. Go get coffee, return, repeat.
4. Write some gibberish. Close without saving. Curse. Tell your workmates how brilliant the proposal was while flaming the software tools industry for allowing innocent users to exit without saving.
5. For inspiration, browse EclipseCon08 papers. Remember how clever that Cory Doctorow was. Go to BoingBoing, read some posts. Follow links to steampunk sites. Puzzle as to why your web browser is open in the first place.
6. While at lunch, suddenly shout out, “Quiet, I’m trying to concentrate!”, then resume eating. Try first in busy cafeteria, then at Wendy’s drive thru for contrast.
7. Get out notepad, a blue pen, and a red pen. In blue write, “EclipseCon09 Submission Outline” at the top. Carefully underline it. Use the red pen for that. Pick up blue pen. Draw happy faces and other favorite doodles. Alternate last step with red pen. Ponder the wonder of color and whether paper and ink is additive or subtractive. Try to remember which pill you were supposed to take in The Matrix.
8. Stare wild eyed at whoever walks into your office.  Try not to listen to anything they say while compulsively glancing back at computer.

With this guidance, I believe you’ll be fully prepared for the inevitable last minute submission panic.

I just read Wayne’s nice blog about accessibility in Eclipse.

As some of you may know, before moving to CS I did three years of Industrial Design. A lesson I always remember is that its a mistake to regard accessibility as a secondary design function. Rather, one must realize that we are all disabled, to some degree, at some point. It could be weak eyesight, RSI, a broken wrist from a skiing accident, tired after a long day… Good design incorporates accessibility from the start.

For example, doorknobs are bad, but door handles are good. Doorknobs require grip strength, thus fail if you have arthritis, hands full with grocery bags, cream on your hands… while as door handles are usable with an elbow, a hip, a cane. Its not that they’re designed to be used in these manners, its rather that the ergonomics are gentler and thus lends itself to different ways of using it.

Eclipse is generally regarded as one of the more accessible IDEs, and I know that the platform and JDT UI teams have always taken it quite to heart (others teams as well, no doubt).  But as someone who has attempted to use Eclipse in large font/low color mode, I would say its accessible but not terribly usable. We’d make certain design trade offs differently if we were working in that mode all the time. For example, maybe wouldn’t show icons in the explorer since they don’t provide enough information to warrant the (now limited) real estate. Maybe the shape of the UI is wrong and we shouldn’t use multiple view stacks, instead focusing on a single display area/stack with changeable content like a web page.  We’d likely get rid of some of the pretty but extraneous, space hogging border treatment.

It turns out that if you try to run Eclipse on a low res device like the Eee PC, you’ll hit much of the same issues.  Thus a device change brings with it some similar trade offs as visual accessibility. Its like as if using the Eee PC suddenly makes your vision poor.  You become “disabled”.   Designing for accessibility meanwhile has the positive side effect of increasing usability on the Eee PC.

In the best design, accessibility emerges naturally as the outcome of a highly flexible and broadly usable UI. Ideally our UIs would transition gracefully to these different usage contexts.

Everyone then wins.

As Boris wrote, we’ve been hacking this nice little photo app demo. I will admit that I wasn’t convinced of the practical advantage of EMF and the modelled UI until I started seeing the demo come together. Now I’m a believer! Mind you, I really suspect that Ed’s been breaking into my house at night, whispering in my ear while I sleep, “EMF is good… EMF is good”. [Note to Ed: you left the fridge door open last time and the milk went sour, please take more care in the future].

The demo has now a second aspect: a tie in with CSS. Thanks Boris, Eric, and Angelo for all the help. Unfortunately this CSS’ed version isn’t available in CVS yet; we need to get Angelo Zerr’s TK-UI code, which although EPL, isn’t IP-blessed into Eclipse yet.

Last Thursday I did a presentation on e4 at the IBM Cracow lab (home to a “small, but good” group of Eclipse Team/CVS/Core/UI committers). I showed the SWTBrowserEdition demo, the EclipseCon08 “Eclipse in a web browser” demo, and finally this cool new Photo App demo.

I started by showing the model instance tree and saying, “This is what the app is, see I have this Albums view, a Preview, …” etc. and everyone nods. You run it, and, well it matches what you were expecting to see. A simple notion but really powerful, with no complex GUI builders trying to hide the truth from you (Jack Nicholson voice, “because you can’t take the truth!”). Well now you can take the truth because its simple!

I then went through the steps of modifying the model directly. “Hmmm, why does this Preview part need to be in a stack all by itself, lets move it up and out”. A simple drag and drop of the element up, followed by a delete of the now empty stack model, then run the thing again … that’s it. People start to get that quizzical “Did he just fool us?” look. Hmm, now that we’ve moved the Preview, its background color needs to change to match the app background, so lets just open up the style.css and make that change of background-color = #ffff…

And boy did they get it!

This combination of 1st class UI structural model which is easy to understand and easy to manipulate, combined with a well separated styling description, is so cool. It just makes sense (ok the web figured that out long ago, we’re a bit late to the party). Its beauty and brains together! I’m genuinely excited about the possibilities for both the ease with which we’ll be able to build apps, and their on screen sophistication. I really do believe e4 could be a whole new era for Eclipse.

Boris showed the bare bones screen cap on his blog, I will repeat it here. This is the typical “what you get for free” Eclipse experience and normally we’d stop there:

We were then quite fortunate to have the help of the always super talented Linda Watson to add her usual sophistication and artfullness to the demo, here is her design:

(click to enlarge)

Linda’s so clever, she even selected a series of artful pictures that were in a complementary color family, so looked nice together in the mockup.

This is what I ended up being able to implement. Pretty close, but sorry Linda, we’re not quite there yet technically (more on that in a future post):

(click to enlarge)

Not your typical Eclipse looking app! I find it quite outstanding the difference a talented graphic designer, plus the ability to easily implement that design, makes.

If you’re in London England on September 19 and want to find out more about e4 and see this new cool work in action, I will be doing this talk again at the first in the BCS fall Software Practice Advancement seminar series. Should be a good crowd, and there’s always pints after!

On our E4 quest for a skinnable UI, tops on my hit list is CTabFolder. Presently that curve is carefully represented by an array of integer pairs, which are interpreted as a polyline draw.  Fast, but extremely fragile.

The problem is that that curve is a really strong branding element of Eclipse. This was done on purpose to great effect. But now in the world of RCP applications, its too restricted.  Its somewhat comical that you can spot an Eclipse application at 2o’ just by looking at the layout (skinny tall left, wide middle, skinny talk right) and those darn tabs.

We should consider a new ETabFolder that takes bitmaps, presumably 8 in total: 4 for each corner, and tile’able sides top\bottom\left\right so the tab length\height can grow.

And of course, the bitmaps would be supplied via CSS