Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "EMF Compare/Specifications/GraphicalComparison"
(→Non conflicting cases) |
m (→Non conflicting cases) |
||
| Line 31: | Line 31: | ||
*Locally added elements: | *Locally added elements: | ||
| + | [[Image:AddLocal.png|300px|Locally added elements]] | ||
| + | |||
| + | You can watch locally added objects on the left side of the comparison viewer. | ||
| + | They are highlighted by a marker in gray color (default color). | ||
| + | On the other side, phantoms with the same color are drawn, as place-holders, in order to locate the places where the related objects would be added if the end-user merged from left to right. | ||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
*Locally deleted elements: | *Locally deleted elements: | ||
| + | [[Image:DeleteLocal.png|300px|Locally added elements]] | ||
| − | + | You can watch locally added objects on the left side of the comparison viewer. | |
| + | They are highlighted by a marker in gray color (default color). | ||
| + | On the other side, phantoms with the same color are drawn, as place-holders, in order to locate the places where the related objects would be added if the end-user merged from left to right. | ||
*Remotely added elements: | *Remotely added elements: | ||
Revision as of 09:35, 4 February 2013
Contents
Evolution Specification: Graphical Comparison
Current status is DRAFT
Preamble
Summary: This feature is about all topics around the comparison of graphical objects.
Links to the Bugzilla tickets which are related to the change:
PENDING
Introduction
PENDING This section should contain a summary of the proposed evolution, including why it is needed. Ideally it should be self-contained so that non-developers can get a quick overview of the evolution without reading the detailed specification.
Detailed Specification
The aim is to be the most consistent with the look of the "semantic" comparison (tree).
To put in relief the graphical differences, some decorators should be used.
- On one hand, it enables to focus on the impacted objects, highlighting them with markers.
- On the other hand, through phantoms, it enables to locate either the place where objects were deleted or the target location where objects should be added after merging.
On each difference selection, only the related markers will appear.
Below, different cases are detailed.
Non conflicting cases
- Locally added elements:
You can watch locally added objects on the left side of the comparison viewer. They are highlighted by a marker in gray color (default color). On the other side, phantoms with the same color are drawn, as place-holders, in order to locate the places where the related objects would be added if the end-user merged from left to right.
- Locally deleted elements:
You can watch locally added objects on the left side of the comparison viewer. They are highlighted by a marker in gray color (default color). On the other side, phantoms with the same color are drawn, as place-holders, in order to locate the places where the related objects would be added if the end-user merged from left to right.
- Remotely added elements:
- Remotely deleted elements:
- Local coordinates changes:
- Remote coordinates changes:
- Local move (and potentially coordinates change):
Conflicting cases
| |
|
|
REMOTE | |||||||||||||||||||||||
| |
|
|
ADD |
DELETE |
Coordinates Change (CHANGE) |
MOVE | ||||||||||||||||||||
| |
|
|
nodes |
children nodes |
parent nodes |
edges |
connected edges |
connected nodes |
nodes |
children nodes |
parent nodes |
edges |
connected edges |
connected nodes |
nodes | children nodes |
parent nodes |
edges |
connected edges |
connected nodes |
nodes |
children nodes |
parent nodes |
edges |
connected edges |
connected nodes |
| LOCAL |
ADD |
nodes |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| children nodes |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| ||
| parent nodes |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| ||
| edges |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| ||
| connected edges |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| ||
| connected nodes |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| ||
| DELETE |
nodes |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
| children nodes |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| ||
| parent nodes |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| ||
| edges |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| ||
| connected edges |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| ||
| connected nodes |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| ||
| Coordinates Change (CHANGE) |
nodes |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
? |
|
|
|
|
| |
| children nodes |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| ||
| parent nodes |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| ||
| edges |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
? | ||
| connected edges |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
? |
|
|
|
|
| ||
| connected nodes |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| ||
| MOVE |
nodes |
|
|
|
|
|
|
|
|
|
|
|
|
? |
|
|
|
? |
|
|
|
|
|
|
| |
| children nodes |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| ||
| parent nodes |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| ||
| edges |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| ||
| connected edges |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| ||
| connected nodes |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
? |
|
|
|
|
|
|
|
| ||
| Conflict (or pseudo-conflict) | |
| ? | Is a conflict ? |
| Potential pseudo-conflict |
- ADD nodes and DELETE parent nodes
- DELETE nodes and ADD children nodes
|
- ADD edges and DELETE connected nodes or edges
- DELETE nodes and ADD connected edges
|
|
- DELETE edges and CHANGE these edges or connected edges or connected nodes
- DELETE nodes and CHANGE connected edges
- CHANGE edges and DELETE connected nodes
- CHANGE nodes and CHANGE connected edges
|
|
|
|
- DELETE nodes and CHANGE these nodes or their children
- CHANGE nodes and DELETE these nodes or their parent
|
|
- MOVE nodes or their children and DELETE these nodes
- DELETE nodes or their parent and MOVE these nodes
|
|
- CHANGE nodes on each side
- CHANGE edges on each side
- CHANGE edges and CHANGE connected nodes
|
- MOVE nodes on each side
|
- The MOVE of a node may involve a CHANGE (coordinates) of it if the new container requires its own coordinate system.
- So, the MOVE would require the CHANGE. But does the CHANGE require the MOVE because it has no sense outside of the context of the MOVE (to merge the change location whereas the frame of reference is different) ?
- Is the MOVE in conflict with a CHANGE if the frame of reference is different ?
Backward Compatibility and Migration Paths
PENDING Every one of the sections below should be present. Even if there is no corresponding change (for example no API change), it should exist to mention explicitly "This evolution does not change any API."
Metamodel Changes
PENDING Document any change to the Viewpoint metamodel. If they require a migration operation, mention it and describe the general idea of how migration process. If any information can be lost during the migration, mention it clearly. If validation rules must be added/modified, mention it also.
API Changes
PENDING List every API addition, removal and deprecation. For each removal and deprecation, indicate the migration path for existing code.
User Interface Changes
PENDING List every user-visible change in the interface. Here "user" includes not only end-users but also developpers.
Documentation Changes
PENDING List every documentation needing an update here, starting by the New and Noteworthy documentation.
Tests and Non-regression strategy
PENDING This part of the document should describe the strategy to use to correctly test the evolution and guarantee the non-regression.
Implementation choices and tradeoffs
PENDING Any important tradeoff or choice made during the implementation should be referenced here with pros/cons leading to the final decision.