[eclipse-incubator-e4-dev] Self Hosting

[Eric Moffatt <emoffatt@xxxxxxxxxx>]

OK then, the summit was a great success
and we're all set to dig in and 'get it done'...now we just have to figure
out what 'it' is...and who's going to do it.

The goal of self-hosting ASAP (M1?)
was raised at the summit based on our experience that eating your own dog
food is the surest way to ensure tasty dog food. If we take this to mean
that we should have an e4 'build' that we use day-to-day to further its
own development what's the shortest path to get this to happen? Note that
we're not saying that at this point we might 'prefer' to use it over the
3.x eclipse, just that it supports our needs,

Also, the decision was made that we
should go 'clean', starting with an empty slate (i.e. no subclassing from
existing code as some of the current demos do). This may mean that we don't
get as much stuff 'for free' but will ultimately ensure a much cleaner
foundation. This doesn't mean that we can't bring over existing Wizards,
Dialogs etc, just that we may have to do some 'porting' along the way.

A typical development work flow (for
me anyway) looks like this:

• Run 'e4.exe' to bring up the 'WorkbenchWIndow' (Workspace switching would be nice but isn't -necessary-, layout persistence -is- necessary though)
• Open the CVS Repositories view, esablish a connection and check-out some source
• Use the Project Explorer to access and open some source...make changes...save (build...)
• Fire up a Debug Launch...do debugging stuff (add breakpoints, look at variables...)
• Check code back into the repository
• Go for lunch, rinse and repeat...;-)

We're going to need at least the following:

• A WorkbenchModel that captures the capabilities of the current eclipse layout and its controls
• A WorkbenchWindow capable of supporting menus/toolbars and stacks within sashes and stack 'content' at the SWT level (i.e. with no other requirements) based on the WorkbenchModel
• Something (Workbench?) acting as the central repository of 'common' information, supplied for the most part through extensions (which views/editors/commands are available...)
• A WorkbenchController of some type that manipulates the Workbench Model in ways that support our work flows (i.e. it adds the correct element(s) into the WorkbenchModel to get a 'view' open...)
• The ability to open views in the layout (whether they work correctly will depend on how deeply they rely on current API/services to do their job)
• The ability to open editors (this likely implies at least some sort of resource model, the current one would suffice for now)
• Enough of the Services infrastructure to enable access to all commands we need to self-host (i.e. not everything has to work but the most commonly used operations have to be available (i.e. Save, Cut/Copy/Paste). This means at least the selection service has to work as well as some concept of part activation (cur view/editor), I'm not sure what else is needed...Paul?

While the CSS/Styling capabilities are
not mentioned (since they're technically not -required- to self host) I'd
suggest that whatever rendering pattern we come up with should support
a styling mechanism 'out of the box', even if it isn't complete.

Are there capabilities we need to self
host that I haven't captured here?

<200 (being generous I think) days
until sefl-hosting,
Eric