Hy Sopot, I created a short demo, and pushed it to gerrit in https://git.eclipse.org/r/#/c/18813/ . A sample plug-in consuming the respective extension point is available on https://github.com/col-panic/generic-stuff/commit/cb4cc272ab4d0da33cd7462519c0ed51231fc029 .
It is intentionally kept simple, and hacked!! So for an element of type MPart you get an additional CTabItem where currently simply the ID attribute is mirrored. It should show the basic concept and point out the required refactorings?! cheers, marco Am 20.11.2013 um 09:59 schrieb Sopot Çela <[email protected]>: > Marco would you be able to make a proof of concept for one element (say > MPart) and throw it on gerrit? I like the idea in principle but it would be > great to have something to see and extend and get the feel of it from my > keyboard. > > Sopot > > > On Wed, Nov 20, 2013 at 8:08 AM, Lars Vogel <[email protected]> wrote: > Hi, > > I think we should avoid a dependency to ECP. > > At some point the tooling should migrate to PDE or platform and these tools > can AFAIK not depend on a higher level in Eclipse. > > Best regards, Lars > > Am 19.11.2013 21:25 schrieb "Jonas Helming" <[email protected]>: > > Hi, > I totally like the idea. However, it reminds me to an idea I have since a > long time, which is related to your question. > When Tom implemented the first version of the e4 tools editor, he actually > contacted me if the EMF Client Platform could be used for this. Back than, > ECP had some restrictions: > > 1. The form-based editor was not really usable stand-alone or embeddable > 2. We did not really support to customize the layout > 3. We did not support a Master Detail view within a form > > In the mean time, these restrictions are not valid anymore: > 1. The editor component can be used stand-alone and embedded everywere, it is > a sub component called EMF Forms > 2. The layout of the form-based UI can itself be described with an EMF model > (see > http://eclipsesource.com/blogs/tutorials/emf-client-platform-how-to-customize-the-editor-layout/) > 3. We currently develop a master detail view, which is almost finished > > Major advantages of this would be IMHO: > 1. The code base of the e4 editor would get drastically smaller and would > only focus on e4 model specific aspects > 2. Custom Applications elements can be edited without any adaption, as ECP > still support reflective UIs > 3. The layout of the editor can be easily customized by users using a view > model > 4. New concepts such as the one you describe can be asily added > 5. The e4 editor would benefit from ECP features, e.g. validation > > The main disadvantage is of course that this would require initial effort. > Your suggested solution is of course much easier to implement for now. > Additionally e4 Tools would get a depenency to ECP. > > I just wanted to share this thought to get peoples opinions. > > Cheers > > Jonas > > > Am 19.11.2013 13:05, schrieb Marco Descher: >> Hy List, >> >> WHAT >> >> I would like to add horizontal extension possibility to the e4 tooling. That >> is, there already is the possibility to add new elements to the application >> model, and provide ones own editors >> for the e4 tooling. I would like to extend the tooling for already >> available elements by adding an extension point to the tooling itself. >> >> WHY >> >> I want to enrich already available elements with additional information. >> This could for example be used to add documentation information to all >> elements of the application model, >> or would allow me to e.g. create an additional tab, valid only if I use the >> SWT renderer, allowing me to do deeper inspection of the model. >> >> HOW >> >> I plan to create an extension point allowing to contribute tabs to given >> elements, as can be seen in the following image. The extension point will >> have to define for >> what model elements the contributed tab is valid, and on call of the editor >> the full model will be passed. >> <Mail-Anhang.png> >> >> Can you please give me any feedback, on what you think about this, who would >> back/mentor this implementation, and what he/she would do different? >> >> Thanks, >> marco >> >> >> _______________________________________________ >> e4-dev mailing list >> [email protected] >> https://dev.eclipse.org/mailman/listinfo/e4-dev > > > _______________________________________________ > e4-dev mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/e4-dev > > > _______________________________________________ > e4-dev mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/e4-dev > > > _______________________________________________ > e4-dev mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/e4-dev
_______________________________________________ e4-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/e4-dev
