Hi, All I can throw into this discussion is https://github.com/BestSolution-at/code-swt - It was a PoC which i did not worked on afterwards.
In the end all main building blocks for editors are in eclipse.text/jface.text who does not depend on any compat-layer APIs. Tom On 04.07.19 10:04, Mickael Istria wrote: > Hi, > > See below a few question, and then some ideas. > >> the core of the Generic Text Editor is not dependent on E3. > > Can you please elaborate what you specifically mean by this? I'm not a > e4 user myself (not really interested in it for my IDE-related work > since e3 just does the job quite well), so I'm genuinly curious about > what specific criteria are to check to claim something is dependent on > e3 or not. > Are there already stories of the Platform TextEditor working on plain E4 > without E3? As long as it's not there, then we cannot really imagine > moving downstream to the Generic Editor. > Also, what is the issue shipping pieces of e3 in an e4 app? > >> trying to remove E3 dependencies from the Generic Text Editor. >> [...] >> I browsed the code of the "ExtensionBasedTextEditor" > > I confirm this is probably quite hard, I guess the type hierarchy of the > editor itself (and it means a lot as parent are providing a lot of the > value) is full of e3 APIs. But maybe I'm wrong on the type stack for the > Generic Editor is already ready. > > > but we can gain a lot from this. > > > Can you please give example of use-case that E4 enables easily that are > impossible or very hard to implement with e3 APIs? > >> The Generic Text Editor may be a good starting point: it has a lot of > services to interact with and it will be natural to utilize OSGi > services and E4 approach. > > If you want to add support for OSGi Services additionally to extension > point in the current Generic Editor, that would be welcome, since it > wouldn't reduce the feature set nor break backward compatibility. > About using the e4 approach, then it seems to me you mean "ability to > load extensions with e4 annotations". It also seems like something that > can be done, if it's not already there. > > Can a pure E4 generic editor be backward-compatible with the current one > (read extensions and process them similarly, and have the same feature > set)? If yes, then I would recommend migrating the porting Generic > Editor rather than creating a new one. If we have both, then it's twice > more maintenance cost, the IDE will keep the legacy one that just works > for it and both editors will ultimately diverge, and given the > priorities of the community regarding text edition (mostly the IDE), > there will be new features in the current Generic Editor that won't be > implemented in the pure-e4 one and the pure-e4 one will get obsolete and > will conclude as an expensive unsuccessful experiment. > For this reason, I'm personally -1 to have Platform hosting a new editor > for this, however, I'm +1 in making the Generic Editor as much > e4-friendly as possible (as long as it doesn't have any negative impact). > > Cheers, > > > _______________________________________________ > platform-dev mailing list > platform-dev@eclipse.org > To change your delivery options, retrieve your password, or unsubscribe from > this list, visit > https://www.eclipse.org/mailman/listinfo/platform-dev > -- Tom Schindl, CTO BestSolution.at EDV Systemhaus GmbH Eduard-Bodem-Gasse 5-7. A-6020 Innsbruck Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck _______________________________________________ platform-dev mailing list platform-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/platform-dev
