| commit | bbac9a8b4dbffb277db91cd3991fbc0683e2c141 | [log] [tgz] |
|---|---|---|
| author | Pierre-Charles David <pierre-charles.david@obeo.fr> | Thu Apr 30 09:06:17 2020 +0200 |
| committer | Pierre-Charles David <pierre-charles.david@obeo.fr> | Tue May 05 15:28:05 2020 +0200 |
| tree | 07befcbc5ebbdeb2dfbf36a7478e1d099580c03c | |
| parent | 6d0cc492a983b587c9ebd09f594dec729c83ed48 [diff] |
[560543] Draw operand labels on a new OVERLAY layer so that they are always readable The overall idea is to add a new "virtual figure" in a new printable layer OVERLAY_LAYER which is placed on top of the others. When painted, the figure finds all the operand label figures and asks them to paint themselves at the proper location (even though they are technically in a different layer). The OVERLAY_LAYER is added in DDiagramRootEditPart. The "virtual figure" is implemented by LabelsOverlayFigure and setup/teared down in SequenceDiagramEditPart activate/deactivate inside this new layer. There are several "subtleties" (or hacks, depending on the point of view) to make this work however: - LabelsOverlayFigure declares bounds that cover all the diagram to avoid clippping issues when drawing the actual labels. However, to avoid "capturing" clicks on the diagram it also overrides findFigureAt() to let them "pass through". - If we let the operand labels draw themselves a first time normally as part of the operand's paintFigure() and *then* draw them a second time later in the overlay, we get slightly bolder labels. This is probably due to some very small difference in how LabelsOverlayFigure computes the labels position (maybe just some rounding error). The current workaround is to customize the implementation of operand labels in a new OperandLabel class which has a global flag to tell it if it should really draw or not. The flag is only set during the LabelsOverlayFigure painting, so the labels are only painted once. - Finally, all of this works fine when displaying the diagram, but not when exporting them as images, because the export process only considers the diagram's primary edit parts, and so does not see the LabelsOverlayFigure (which is not associated to any edit part). To work around this, both SiriusDiagramImageGenerator and SiriusDiagramSVGGenerator override renderToGraphics() to paint an optional overlay figure *after* (and thus on top) the primary edit parts, if the diagram provides such an overlay (only SDEP does at the moment). Bug: https://bugs.eclipse.org/bugs/show_bug.cgi?id=560543 Change-Id: I4e5acdf155a6bf5d664c243681bbe1a7dc8fac8c Signed-off-by: Pierre-Charles David <pierre-charles.david@obeo.fr>
Sirius enables the specification of a modeling workbench in terms of graphical, table or tree editors with validation rules and actions using declarative descriptions.
For more details see the project page and the main wiki page.
The build uses Tycho. To launch a complete build, issue
mvn clean package
from the top-level directory. The resulting update-site (p2 repository) can be found in packaging/org.eclipse.sirius.update/target/repository.
By default the build uses a Neon-based target platform. You can specify a different platform like this:
mvn clean package -Dplatform-version-name=name
where name can be any of the following values:
mars (Eclipse 4.5)neon (Eclipse 4.6, the default and reference target platform)canary (uses nightly builds of all our dependencies, only used for testing)The corresponding target platform definitions can be found in releng/org.eclipse.sirius.targets.