Thanks Marco, I'll take a look and get back to you. Sopot
On Mon, Nov 25, 2013 at 12:57 PM, Marco Descher <[email protected]> wrote: > 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 >>> [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 > >
_______________________________________________ e4-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/e4-dev
