Re: [platform-ui-dev] Some thoughts on the E4 compatibility story

[Eric Moffatt <emoffatt@xxxxxxxxxx>]

Brian, first I've gotta say that I really
like your comment about Eclipse 4 separating the UI 'mechanisms' from the
UI 'policy'...can i use this at EclipseCon ? (properly attributed of course...;-).

To echo John I'm in complete agreement
that we should never mention 'compatibility layer' again.

The taxonomy that I've used (somewhat
loosely) goes like this:

e4: The underlying 'core' API (model
/ DI + a very few services EModelService, EPartService, EventBroker...)

EAP (Eclipse Application Platform  
aka RCP 2): Aproject based on e4 providing a simple application life cycle
but that does not support legacy eclipse components like views. In incubation
but gestating nicely

Eclipse 4: The re-implementation of
the Eclipse 3 UI 'policy' and API using e4.

Note that we already have plans for
trying to move a variety of views (editors?) out from under the legacy
API, allowing them to be directly used in EAP apps without having to bring
in the whole of Eclipse 4. Note that while this will produce some convergence
we never expect to move everything since very few apps are as complex as
the IDE itself

What we're still trying to determine
is how we should update (add?) the existing Eclipse API / extensions to
make it easy for clients to start writing their Eclipse code against e4.
For example updating the 'org.eclipse.ui.views' extension point to allow
for the definition of a view that is based on e4 API.

Brian, it sounds like your clients might
make an excellent candidate for the first product that uses the second
option. They could write all their views / editors / command handlers...using
e4 but running in the Eclipse 4 IDE (so they can get all the other extensibility
and services they need). This is the correct approach IMO for someone that
wants full-blown eclipse but doesn't care whether it has to run on 3.x..

In any case thanks for the 'real world'
observations, they're really the most valuable kind...
Eric

From:	John Arthorne/Ottawa/IBM@IBMCA
To:	"Eclipse Platform UI component developers list." <platform-ui-dev@xxxxxxxxxxx>
Date:	12/05/2011 10:23 AM
Subject:	Re: [platform-ui-dev] Some thoughts on the E4 compatibility story
Sent by:	platform-ui-dev-bounces@xxxxxxxxxxx

---

Hi Brian, 

I completely agree with you about the term "compatibility layer"
being confusing and inaccurate. It gives the impression this is a shim
that can be pulled out once you have fully adopted the Eclipse 4 APIs.
This is not the current reality and I doubt it ever will be for people
building IDEs. I have been trying to characterize it as "the Eclipse
4 implementation of the workbench API". That's a bit of a mouthful
so I definitely like the idea of a better term for it. Maybe just "Eclipse
4 workbench". I agree with your description that this is building
a particular IDE paradigm/policy on top of the general E4AP infrastructure.
I'm not really keen on your suggested terms that include "3.x"
in the name though, since this also implies it is old technology that can't
be relied on in the long term. 

On the topic of going back to calling Eclipse 4 Application Platform simply
"e4"... I agree this has been a slow struggle but there is also
a downside to going back to the term e4 to encompass both incubating and
graduated technology. In practical terms e4 is still officially an incubator
at Eclipse and can't ship non-incubating code. There has to be a way to
distinguish all the various ongoing incubating work from the more mature
stuff that is in the Eclipse 4.x stream, at least within the small circle
of people following the project closely. For the vast consumer community
it's not the end of the world if they erroneously conflate "e4"
and "Eclipse 4 Application Platform". 

John

Brian de Alwis <briandealwis@xxxxxxxxx>
Sent by: platform-ui-dev-bounces@xxxxxxxxxxx

12/04/2011 11:19 PM

Please respond to
"Eclipse Platform UI component developers list."        <platform-ui-dev@xxxxxxxxxxx>

To	E4 Project developer mailing list <e4-dev@xxxxxxxxxxx>, "Eclipse Platform UI component developers list." <platform-ui-dev@xxxxxxxxxxx>
cc
Subject	[platform-ui-dev] Some thoughts on the E4 compatibility story

I've been helping a company to move their application suite from a homegrown
Swing-based application framework onto Eclipse.  In discussions, I've
come to realize that our messaging around the compat layer is causing some
confusion, and I think we should adapt our story around the compat layer.

This company's goals are to leverage the extensibility of the Eclipse platform
to open up their suite to extension by their customers.  They're really
excited by the CSS styling, DI, and the IEclipseContext.  Although
their application suite is very well-suited to the E3.x UI model (views,
editors), and they really like some of the E3.x UI technologies (e.g.,
cheat sheets, intro), our use of "compatibility layer" is off-putting:
the implication is` that it's strictly for legacy applications that cannot
be converted the E4 APIs, and not recommended for new green-field development.
 Since their transition will be a big effort that they hope will carry
their suite for the next 5-10 years, they don't want to move to something
perceived as being "yesterday's technology".  But to implement
what they want on a pure E4 foundation will effectively re-create the compat
layer, which seems rather counter-productive.

In thinking about it a bit, I realized that the real achievement of the
E4AP effort has been to split the Eclipse UI mechanisms from the UI policies.
 Eclipse 3.x implemented a particular UI paradigm based around strong
notions of views and editors, but it was a poor fit for apps that don't
want to buy in to that UI paradigm.  With Eclipse 4, apps can implement
their own UI paradigms, like I did for Kizby.  Seen in this light,
the compat layer is really an implementation of such a UI paradigm.

My suggestion is that we should re-cast the compat layer as an "E3.x
UI Paradigm" or "E3.x UI Policy layer" or "E3.x UI
Framework" (vs platform), or something to that effect.  I personally
like "framework" as a counterpoint to a "platform"
— it implies any app written to the E4AP layer will likely require writing
some plumbing to implement their own UI framework onto the minimalist policies
defined by the platform.  Our E3.x UI framework then has two parts,
one implementing the E3.x UI model using the E4 platform, and the other
being a translation layer for older configuration methods into the E4 equivalents
(e.g., the UI extension points, action sets).

To that effect, I think we should (and I will) start documenting how the
compatibility layer (or whatever we call it) works, such as the expected
tags on parts to distinguish an editor from a view, and how a more E4-focused
plugin can safely interact with the E3.x UI Policy layer.  After all,
it would be great for devs to be able to develop against the App.e4xmi.
 Perhaps we should have a PerspectiveDescriptor?

[And while I've brought up naming, perhaps we should accept that the e4/E4AP
distinction has been lost for ever, and we should just call the E4AP as
"E4", like others are?]

Brian.

_______________________________________________
platform-ui-dev mailing list
platform-ui-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/platform-ui-dev

_______________________________________________
platform-ui-dev mailing list
platform-ui-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/platform-ui-dev