There has been a growing discussion around the fact that Eclipse should look and behave less like an IDE. It was a recurring topic at the e4 Summit, and is a topic near to the hearts of many an RCP developer.

I came across the following help documentation while working on 3.4 help context IDs, this is from org.eclipse.platform.doc.user contexts_Workbench.xml (shows up in Preferences->General->Workspace):

<context id=”workspace_preference_page_context”>
<description>
This preference page is used to set the IDE-specific preferences settings related in workspace.
</description>
</context>

This description made sense during Eclipse 1.0 (probably when it was written) but for any RCP app that wants to reuse this rather general preference page its a real problem. While so far we’ve been focused on the architecture and API, this IDE/non-IDE split will surface in a surprising number of places. How do you reuse Help doc when you don’t know the context of usage?

Hmmm, this is going to be even tougher than I thought!

The e4 summit is coming up end of this week and as I was preparing my position paper for it, I pondered the question,

“What should Eclipse look like?”

I then realized that Eclipse shouldn’t look like anything! It’s like asking, “What should a web page look like?”. Different web pages, geared towards different communities, have very different looks. Even within a specific area like B2C e-commerce, Amazon pages have a recognizable style and interaction which at a glance fundamentally differentiates them from say BestBuy.

However, when I survey the set of Eclipse applications they all at a glance yell “Eclipse!” more than they yell their respective companies or domains. That’s not through some kind of laziness or lack of caring on the part of the developers.

Eclipse started out as an IDE. Many decisions were burned in early on. Due to either API compatibility or preconceptions which now put blinders on us, we’ve not strayed all that far. We’ve grown some Presentation level APIs for doing small things like deciding tab style (one of two, you chose!), hiding perspectives, etc., but these have been added piecemeal in reaction to specific community requests. So we’ve been able to open things up a little, but relatively speaking, its still a pretty closed world. Any variance you see is mostly a testament to the incredible determination on the part of application/RCP developers.

At the platform level, updating the look of Eclipse ends up being fantastically controversial, and not surprisingly, given that every change on the glass we make, no matter how small, decides what every Eclipse application looks like. Its close to impossible to make the right decision for so many different kinds of applications and users. But that puts us on the path of least resistance, which means things stay the same. As time goes on, Eclipse is looking rather, well dated. To change things, we will need to see some fundamental shifts in the Eclipse frameworks and components.

I am therefore very excited about the possibilities in e4. The summit has some great topics listed, like:

• Declarative UI
• Styling/CSS
• Modelling the Workbench
• Rich Client Platform

My hope is that in the future, there will exist graphically rich, subtly styled, dare I even say sexy, Eclipse based applications where the only place they reveal their Eclipse technology basis is in the About.