Thursday, June 05, 2008

E4 is more about bringing it to the web

Since the E4-Presentation at EclipseCon and the SWT-Talk most people think that E4 is only about bringing Eclipse to the web. THAT'S NOT TRUE.

E4 is much more and that SWT gets a web-port is only a small part. Here's my top list of things for E4:

  • Modeldriven:
    One extensible model backing up the whole workbench

  • DOM: At the moment the Workbench is backed up by ONE model you automatically have a DOM and you can do with this DOM the same you do in Web-Applications (See my prototype)

  • New Resource Framework:
    Making handling resources much more Flexible

  • New Listener Concept:
    The current listener concept in eclipse sucks and makes eclipse slower than it could be

  • NO SINGLETONS AND STATIC FIELDS

  • Plugins in NONE-Java: Make it possible to write an Eclipse-Plugin in other languages (JavaScript, ...)

  • Declarative UI, Easier Styling .... and much more

6 comments:

L. Mihalkovic said...

... which prompted my comment:

"as a gear-head I understand the entertainment value I would derive from working on it, as a technology consultant, user of the SWT/RCP platform, I fail to see some of the relevance"

Much of what you describe is evokes to me the laundry list of a mechanic captivated with the sound his own tools make when he tinkers with them inside a fascinating new engine. I somehow believe that making good decisions is not just exploring permutations, it is exploring within all possible permutations, the rational and potential derived value of each one in order to rank them.

My personal sense of the E4 stated goals as they were communicated so far was that their were devised in a complete vacuum by a tiny group of crafty mechanics, who would probably hard-pressed to remember what was happening outside the room, let alone anywhere in the community of their user base... Decoded: how is any of that addressing some of the hundreds of current issues and requests?

Tom said...

Well I hate the fact that people only think that e4 is something that affects SWT. I wanted to emphasize the fact the e4 is more.

I appreciate the work you are doing on the SWT side. Clean up the platform internals is task which very important.

I even think the core should make it possible to exchange the underlying widget technology (You are not satisfied with SWT anymore you can use QT, Swing, ... ) should be possible. What you still have is a extensible platform providing a framework to you.

I'm just changing my prototype code to show how this is possible. Cleaning up the internal mess is as important for the success of Eclipse/RCP as it is to explore new SWT-features. Keep up this good work. Tom

Anonymous said...

Why does people have to destroy what they have done?
# Modeldriven: mental disease not based on evolutive solutions
# NO SINGLETONS AND STATIC FIELDS : maybe developpers care about these details but who else?

The flexible ressource framework is the good news for E4 from what it seems...

Tom said...

Nobody has to destroy anything, E4 has a backwards compat layer.

Modeling:
---------
Modeling the internals of the workbench doesn't affect you the developers if they don't care but please compare the internals of the current prototype and original code that was needed to provide these features. The internal Model also helps to add Scripting and DOM-Features to the workbench.

NO SINGLETONS and STATIC FIELDS
-------------------------------
This heavily affects users because with this they can have as many workbenches running in the same OSGi-Instance as they want.

Anonymous said...

Sorry for being rude, but i didn't know the consequences of static fields. I still wonder if such a modellign effort is needed.

Tom said...

Well we could but then we would have to code everything by hand (bi-directional relationships, notification support, ...).

I don't know if you already worked with EMF but it's not as intrusive than other modeling technologies. EMF also opens a complete stack of new things for use and directly supports Eclipse-Databinding so the Model <=> UI connection is done with a very small amount of code.

Check out the current demo code and the blog post from Ed and the blog post from Boris.