[News.eclipse.foundation] Re: E4 / SWT 4.0

[Tom Schindl <tom.schindl@xxxxxxxxxxxxxxx>]

[...]

> > There are lots of examples like this in the computing world. Do you 
> > think Apple would still exist if they had continued to fix each and 
> > every bug in Mac OS 9 rather than making a cut and moving everybody 
> > over to Mac OS X with a solid BSD base? Don't they screw everybody 
> > over again by discontinuing Carbon and making Cocoa development a 
> > requirement? I am sure they haven't fixed all the bugs in Carbon 
> > before they moved their developers over to Cocoa.
>
> The Apple examples are excellent ones, and I understand the point behind 
> them. In terms of the M$ comparison, I was referring to Office, XP and 
> Vista where we keep getting more and more eye candy and other features 
> we don't need while numerous bugs and major usability problems are left 
> unaddressed. Office, especially, has major problems with that.
> Anyway, your point is understood; but it does not trump everything, and 
> my point about conflicting messages ("we need more people to help" vs. 
> "let's dedicate significant time and effort to e4") is also still valid, 
> I think.

IMHO the current codebase makes it so hard to add a new feature (e.g. 
talk to Eric and ask him how long it took him to implement a small 
feature into the presentation layer) that a cut is needed. Eclipse 
*needs* a solid base to stay the number 1 platform for the foreseeable 
future.

Some of the features requested can't get implemented because they have 
such a deep impact on the whole platform that you can't do them 
individually or if you do that the platform internally needs compatility 
layers and slows done because of this.

If you take a look how many troubles P2 had in the last months you can 
estimate how many troubles you'll get when you e.g. change the 
resource-management.

> > The reason we are working on e4 as well as (not instead of!) the 3.x 
> > stream is that we believe that Eclipse as a component integration 
> > platform will not exist five or ten years from now unless we re-invent 
> > it in a way that makes Eclipse relevant to programmers using other 
> > programming languages, developers working on distributed applications, 
> > and users who would like to see (parts of) the functionality they use 
> > in an Eclipse-based desktop application in a browser. We will not 
> > achieve all of these goals within the next few months, but I think 
> > they work well as a vision for what we are aiming at.
>
> While I agree with some of those assertions, I don't agree with them all 
> (and for most of them, my degree of confidence is relatively low). For 
> example, I don't agree that every software technology needs to have a 
> browser-based strategy. I'm not alone in predicting that the current 
> level of hype and mania may not sustain.
> My broader point, regardless of the detailed ideas and decisions 
> constituting the vision, is this: who is setting this vision and how can 
> the community have more influence into it (in a meaningful way, not just 
> as a token: "Yes, thanks for your opinion")? I find things to be too 
> opaque and difficult to enter for the community in general and am trying 
> to use this thread to raise awareness of that to the committers and 
> project leaders.
> BTW, I really do appreciate the participation in this thread that we're 
> getting - it is a good sign, I think. I encourage more community members 
> AND project committers to chime in so it's not just the loudmouths like 
> me being heard ;-)

If you look at the discussion on the e4 mailing list one notices that 
the browser stuff is only *one* point of the big picture (CSS doesn't 
count). It's right that the browser point has some influence on other 
topics (e.g. multiple workspaces in one OSGi) but this will also help 
Desktop-Eclipse.

In my radical way of thinking I even started to split out SWT specific 
view in my prototype and make it replaceable with anything you want 
(e.g. an GEF based implementation).

It's right that some of the resources available are shifted to e4 but 
not doing this we are stuck in a few years from now. As Boris points out 
bugfixing in 3.x as well as introducing new features (not as radical new 
ones as you'll get in e4). I could even think that new features added to 
e4 can get back ported to 3.x.

IMHO currently is the right time for e4. There are the people around who 
know what they did wrong in 3.x and how they can improve it in e4.

Tom

--
B e s t S o l u t i o n . at
--------------------------------------------------------------------
Tom Schindl                                          JFace-Committer
--------------------------------------------------------------------