[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [eclipse-incubator-e4-dev] How many pieces for the workbench?


Pascal, this is one of the main design goals of the new approach. The ability to start out with a simple structure and add what you require as needed (sort of a 'lego' block assembly approach), all the way up to functionality at the current workbench level (give or take...;-).

I'm not sure about the views/editors statement though. We're trying to eliminate the current distinctions between these in the new framework (a la Stefan's 'Component' model). We already have 'saveable' views and editors that are not truly backed by a file. The view/editor distinction has more to do with 'policy' (i.e. 'Editors' are only allowed to be added to the 'editor area' stacks) but their underlying implementations should be the same or,. at minimum, share a common protocol for saving...

Onwards,
Eric



Pascal Rapicault/Ottawa/IBM@IBMCA
Sent by: eclipse-incubator-e4-dev-bounces@xxxxxxxxxxx

09/08/2008 09:22 AM

Please respond to
E4 developer list <eclipse-incubator-e4-dev@xxxxxxxxxxx>

To
E4 developer list <eclipse-incubator-e4-dev@xxxxxxxxxxx>
cc
Subject
[eclipse-incubator-e4-dev] How many pieces for the workbench?





On thursday, Boris gave me an impromptu demo of e4 (what he describes
here). This was really cool. He emphasized the coolness of the model
and the ability to just open an EMF editor to change the layout.
What stroked me was the ability to have a very small app cleaned up of
a whole set of gorp that usually constitutes the workbench (e.g
registries of all sorts).
This is great and very powerful and I believe that even though the goal
is to recreate a workbench with functionalities equivalent to those of the previous
one, we should strive to keep this nice separation of concern to give
ppl the ability to write the smallest application possible and also give
them the ability to use just what they need. For example an application author
could pick and choose workbench constructs by just adding a few more
plug-ins (view support should be separate from the editor support, etc.).
Likewise, if he wants extensibility for views, he could just
drop a few additional plug-ins.

Do we believe this is an interesting direction and we should strive to
keep this kind of separation?
_______________________________________________
eclipse-incubator-e4-dev mailing list
eclipse-incubator-e4-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipse-incubator-e4-dev