Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "EMF Compare/Specifications/EnhanceReadabilityOfTheStructuralDifferences"

(New page: = Evolution Specification: Enhance readability of the structural differences = Current status is '''DRAFT''' == Preamble == The difference labels displayed in the structure merge view...)
 
Line 22: Line 22:
 
== Detailed Specification  ==
 
== Detailed Specification  ==
  
TODO.
+
Proposals :
 +
 
 +
*version 1
 +
 
 +
[[Image:EMFCompare2-StyledLabels_v1.png|alt Styled Labels v1]]
 +
 
 +
*version 2
 +
 
 +
[[Image:EMFCompare2-StyledLabels_v2.png|alt Styled Labels v2]]
 +
 
  
 
== Backward Compatibility and Migration Paths  ==
 
== Backward Compatibility and Migration Paths  ==

Revision as of 05:41, 16 January 2013

Evolution Specification: Enhance readability of the structural differences

Current status is DRAFT

Preamble

The difference labels displayed in the structure merge viewer can be quite difficult to read and understand.

_Relevant tickets_ (links to the Bugzilla tickets which are related to the change):

  • Bug 398099 - Enhance readability of the structural differences

Introduction

We propose to add some styling to these label to more easily identify:

  • if the difference is local or remote,
  • The difference kind (addition, change, deletion, move),
  • the structural feature affected by the change,
  • the label of the element that has changed.

For this purpose, we will use styled texts in the label provider.

Detailed Specification

Proposals :

  • version 1

alt Styled Labels v1

  • version 2

alt Styled Labels v2


Backward Compatibility and Migration Paths

Metamodel Changes

This evolution does not change the metamodel.

API Changes

TODO. (List every API addition, removal and deprecation. For each removal and deprecation, indicate the migration path for existing code.)

User Interface Changes

TODO. (List every user-visible change in the interface. Here "user" includes not only end-users but also developpers.)

Documentation Changes

TODO. (List every documentation needing an update here, starting by the New and Noteworthy documentation.)

Tests and Non-regression strategy

TODO. (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

TODO. (Any important tradeoff or choice made during the implementation should be referenced here with pros/cons leading to the final decision.)

Back to the top