Home » Modeling » EMF Diff/Merge » Plan to support e4 UI?(Plan to support e4 UI?)
| Plan to support e4 UI? [message #1782063] |
Fri, 16 February 2018 11:54  |
Eclipse User |
|
|
|
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.
|
|
| |
| Re: Plan to support e4 UI? [message #1782390 is a reply to message #1782181] |
Thu, 22 February 2018 11:00  |
| Eclipse User |
|
|
|
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 11:06] by Moderator |
|
| |
| Re: Plan to support e4 UI? [message #1782843 is a reply to message #1782463] |
Fri, 02 March 2018 07:01 |
| Eclipse User |
|
|
|
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 07:02] by Moderator |
|
|
| Re: Plan to support e4 UI? [message #1782959 is a reply to message #1782843] |
Mon, 05 March 2018 11:03 |
| Eclipse User |
|
|
|
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".
|
|
|
| Re: Plan to support e4 UI? [message #1783734 is a reply to message #1782959] |
Fri, 16 March 2018 08:31 |
| Eclipse User |
|
|
|
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.
|
|
|
Goto Forum:
Current Time: Mon Jul 14 04:00:31 EDT 2025
Powered by FUDForum. Page generated in 0.60379 seconds |
Home