Eclipse Community Forums: EMF Diff/Merge

Help

Home

Home » Modeling » EMF Diff/Merge » Plan to support e4 UI?(Plan to support e4 UI?)

Show: Today's Messages :: Show Polls :: Message Navigator

Plan to support e4 UI? [message #1782063]

Fri, 16 February 2018 16:54

Erik Lundström

Messages: 22
Registered: July 2009

Junior Member

Hi there,
I am using EDM successfully for several years now within our application. I think I started out with version 0.2.0, and the application currently uses EDM 0.5.0. I have done some own work "on top" of EDM to tailor it to our purposes (e.g slight adaptation of UI to better suite our needs).
Currently, we are migrating our Eclipse application to e4, which of course is quite a bit task, given that our ambition is to "go all in" on e4. What that basically means is that all "org.eclipse.ui.*" dependencies will have to go.

My question is, if there is any plan to develop a UI that is not dependent on the old e3 platform and workbench ui code? The way I see it, we will have to ditch the UI plugin (org.eclipse.emf.diffmerge.ui) dependency in our application, since it cannot be used in a pure e4 application.

Report message to a moderator

Re: Plan to support e4 UI? [message #1782181 is a reply to message #1782063]

Tue, 20 February 2018 09:24

Olivier Constant

Messages: 106
Registered: January 2012

Senior Member

Hi Erik,

It is nice to know you found EDM helpful. Typical adaptations of the UI we have seen include skipping the impact dialog (which is not quite useful for most end-users) and the "include differences in children" dialog on non-leaf elements, and enforcing certain visualization options that can otherwise be set via menu items. I'd be curious to know what adaptations you made, if you feel like mentioning them.

Now, to answer your question: no, unfortunately, we do not plan to provide an e3-independent UI.

Report message to a moderator

Re: Plan to support e4 UI? [message #1782390 is a reply to message #1782181]

Thu, 22 February 2018 16:00

Erik Lundström

Messages: 22
Registered: July 2009

Junior Member

Thank you for your reply, Olivier. Sure, I'd be happy to mention the adaptations we've made. What would be the preferred method of communicating them to you?
Regarding the "3.x workbench vs e4 topic": Since it is really important for us, I have decided to go ahead and fork from the github mirror of emf.diffmerge.core. My fork is here: https://github.com/Lulle74/emf.diffmerge.core
My ambition is similar to what's suggested here: https://www.eclipse.org/forums/index.php/t/1087233/ That discussion relates to the bundle "org.eclipse.compare" from the Platform/Team project, and the bug of interest is this one: https://bugs.eclipse.org/bugs/show_bug.cgi?id=473847 There is a Gerritt change connected to the bug.

So in essence, what I am setting out to do could be called "Minimum E4 Compability of EDM UI" I guess. As you can see, I have started the work a little. There will be some safe-guarding (e.g. checking whether PlatformUI.isWorbenchRunning(), and then trying to have options for both the 3.x wb case and when it's not running). I hope that all functionality will be maintained also for the non-3.x case, but am not sure yet (For instance, I do not yet know what would be the alternative to the "PlatformUI.getWorkbench().getOperationSupport()" code in the class EMFDiffMergeEditorInput). Also, since my EDM knowledge is both a little rusty and dated (the code in the product of my company relies on EDM 0.5.0), there may be things I am not aware of yet. I have no experience with the GMF or Sirius extensions yet (we only used the "diffmerge" and "diffmerge.ui" bundles so far).
I would of course be happy to hear your thoughts on this, Olivier.

Edit: This strategy is of course somewhat different to what I outlined in the original post, where I was adamant that our product should avoid all dependencies to "org.eclipse.ui*" bundles. We will try to find some middle ground, basically (the alternative is too big a task right now).

[Updated on: Thu, 22 February 2018 16:06]

Report message to a moderator

Re: Plan to support e4 UI? [message #1782463 is a reply to message #1782390]

Fri, 23 February 2018 17:09

Olivier Constant

Messages: 106
Registered: January 2012

Senior Member

- Adaptations you have made
To answer your question: feel free to open a Bugzilla on this (product=EMF.Diffmerge). If the motivation for some of those changes turns out to be relevant outside the context of your application, then maybe we should consider making the same changes in the default UI.

- getOperationSupport()
The corresponding line aims at suppressing a memory leak. The leak is due to the undo/redo operation history: if nothing is done, the history keeps Java references to the (possibly huge) comparison even though the comparison editor is closed. There are likely to be better ways to handle that issue, but I'm not sure. I do not know how much the operation history is tied to the e3 workbench, but in any case the absence of memory leaks will need to be analyzed in the e4 application regardless this particular issue. So I would say you can just safe-guard the line in the meantime.

- GMF & Sirius extensions
There was a talk at EclipseCon France last year regarding GMF and Sirius in e4: https://www.eclipsecon.org/france2017/session/embedding-sirius-pure-e4-application-lessons-learned-and-future-plans
It seems that right now there is no "official" adaptation of GMF or Sirius for e4 applications so adapting the EDM extensions is probably not relevant at this time.

- Overall endeavor
Thanks for your explanations. Feel free to ask more questions if you encounter other specific issues in the code. If you are successful, I'll be interested to see if the resulting code is not too complex and if it seems relevant to integrate the changes in the Eclipse EDM repo.

Report message to a moderator

Re: Plan to support e4 UI? [message #1782843 is a reply to message #1782463]

Fri, 02 March 2018 12:01

Erik Lundström

Messages: 22
Registered: July 2009

Junior Member

Hi again,
I have analyzed the code in the "Diffmerge UI" plugin (and downstream plugins in the project repo), and I think it very well may be possible to (again) widen the scope of what I will do. My aim will be, in my fork of the "emf.diffmerge.core" repository:
- define new "Diffmerge E3 Workbech" plugin.
- move PlatformUI AND other "org.eclipse.ui.*" dependencies from "org.eclipse.emf.diffmerge.ui" to the new E3 Workbench one .
- Thus, the Diffmerge UI plugin be pure JFace and SWT.
- Also, I will strive to also move the dependency on the "org.eclipse.emf.edit.ui" to the new E3 Workbech plugin.

Of course, I need to investigate a little bit more, but it looks doable to me.
If I succeed in this, the application I am part of developing will build on the following (tweaked) EDM plugins only:
- o.e.e.diffmerge.structures
- o.e.e.diffmerge
- o.e.e.diffmerge.ui (now having a clean JFace/SWT UI)

Our application will benefit of this, since:
* In our applications' plugins projects, we are totally rid of "org.eclipse.ui.*" code
* We do not have the "org.eclipse.ui.*" stuff re-exported by other plugins. This is valuable to us.

We would of course still not be able to build without "org.eclipse.ui" (due to "org.eclipse.compare" still not being split into workbench-independent + workbench-dependent parts). But it is a step in the right direction.

[Updated on: Fri, 02 March 2018 12:02]

Report message to a moderator

Re: Plan to support e4 UI? [message #1782959 is a reply to message #1782843]

Mon, 05 March 2018 16:03

Erik Lundström

Messages: 22
Registered: July 2009

Junior Member

Hello,
I've had time to do some work, and in my fork https://github.com/Lulle74/emf.diffmerge.core, I have made a rather large commit.
(Note: I have not been able to test it extensively yet, since my current target plaform is "an e4 one", and lacking both GMF and/or Sirius, among other things. The "basic API" of the "Diffmerge" plugin, plus the revised "Diffmerge UI" plugin has been tested however in an E4 environment. )

A couple of words on the separation I have done.
- org.eclipse.emf.diffmerge.ui is independent of 3.x workbench
- org.eclipse.emf.diffmerge.ui is independent of "org.eclipse.emf.edit.ui"
- The new bundle "org.eclipse.emf.diffmerge.ui.workbench": Have refactored/moved the 3.x wb dependent stuff into here, plus the stuff depending on "emf.edit.ui"

There are a few things that may be considered odd:
* The "drop-in" replacement of all those ISharedImages icons (not available on e4). I bundled ALL the relevant icons in the "Diffmerge UI" plugin...I do not know what you think about that. But it will work of course on both E3/E4 platform.
* When running with the new "Diffmerge UI Workbench" plugin, some service-like classes have their implementation changed during runtime. See the Activator.start() in the new plugin. (I did it like this, to attempt to keep the API as similar as possible, and with as small as effort as possible.)
* Some refactorings+separations led to a class with orig name in original plugin, plus a new class, typically with "..E3.java" suffix. Not very nice naming pattern, but I could not come up with better.
* I have a feeling that a few (revised) class hierarchies may not be optimal yet. For instance, the hierarchy of AbstractComparisonViewer feels a bit "odd".

Report message to a moderator

Re: Plan to support e4 UI? [message #1783734 is a reply to message #1782959]

Fri, 16 March 2018 12:31

Olivier Constant

Messages: 106
Registered: January 2012

Senior Member

Hi,

Nice it works in an e4 TP, that is an achievement.

- About the "drop-in" replacement of the ISharedImages: I don't see a better solution, and it is only about a few icons after all, so my feeling is that it is OK like this.

- About the service-like classes: I am not shocked at all that the configuration of "services" is set up at plugin activation time, if it is what you mean.

- The .E3 classes: Perhaps having some consistency between the "ui.workbench" plug-in name and the naming of the E3 classes would make it more obvious that both are related. But... I'm not making a precise proposal. :)

- The hierarchy of AbstractComparisonViewer: I agree. The absence of multiple inheritance in Java does not help separate concerns / technological dependencies. At first sight, I would suggest to replace AbstractComparisonViewerE3 by a concrete class that can be aggregated by E3 classes in the AbstractComparisonViewer hierarchy. In other words, replace inheritance by delegation to achieve reuse, the delegate doing nothing in a non-E3 class. But that's certainly not as important as making sure that all works well.

Report message to a moderator

Previous Topic:	Co-Evolution Basic Concepts
Next Topic:	Coevolution with diffmerge.mapping : referenced objects

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

]

Current Time: Thu Apr 25 08:43:15 GMT 2024

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter