|
|
| Re: Programmatically opening compare editor [message #1048277 is a reply to message #1048210] |
Wed, 24 April 2013 04:47   |
 Victor Roldan Betancort
Messages: 489
Registered: July 2009 |
Senior Member |
|
|
Laurent,
first of all, thanks for your prompt feedback
Quote:
Yup, that was the main reason for 2.0 : to break everything apart .
More seriously, though we did break everything, the goal was to get rid of the limitations of the previous architecture . We hope that this will be your general feeling too as a client of the API .
Do not hesitate to ask if you think some of compare's internals should be exposed : the new API is meant to be much more extensible, but may still be missing bits and pieces.
At first glance, things make much more sense now, cleaner and full of nice APIs to be extended / implemented. Previously, customizations of the comparison engines required some nasty hacks.
Now I'm trying to figure out how to migrate all that logic, hopefully I would be able to get rid of a big part of it.
Quote:
ICompareEditingDomain is part of org.eclipse.emf.compare.edit.
ha! so thats the reason I couldn't find it, missing ".edit" in the namespace. I thought best practices pushed us to use bundle namespace in the java packages too. My first though was that .edit bundle corresponded to old's 1.X emf's .edit framework generated bundle. I see this is something different now in 2.X.
Quote:
I am pretty sure this was meant to be public API. Mikaël, could you take a look?
Very much appreciated!
Cheers,
Víctor [Open Canarias]
|
|
|
| Re: Programmatically opening compare editor [message #1048994 is a reply to message #1048277] |
Thu, 25 April 2013 04:03 |
Mikael Barbero
Messages: 38
Registered: July 2009 |
Member |
|
|
Hi Victor,
BTW ComparisonEditorInput is internal, is there any legit way to get it?
ComparisonEditorInput really is internal currently because we are not confident about its API yet. You may use it, but we may break its API sooner or later. Actually, I'm thinking of removing this EditorInput in favor of ComparisonScopeEditorInput which is more flexible and which let the UI know about the scope which is not possible from the Comparison's one.
My advice would be to duplicate the code for yourself if you need stability over the next release or to rely on ComparisonScopeEditorInput which I hope to be more stable.
Hope this helps.
Best regards,
Mikael
Best regards,
Mikael Barbero
Obeo
|
|
|
|
|
|
Powered by
FUDForum. Page generated in 0.02877 seconds
] 
Search
Help
Register
Login
Home
Jokes aside, the new API seems to solve much of the extensibility issues I had with 1.3. The effort is pretty much welcome!
.
. We hope that this will be your general feeling too as a client of the API 
.