Community
Participate
Working Groups
It should be possible for specifiers to define, in the VSM, a background color and/or image to use for a representation. The most obvious is on diagrams, but we have feedback from some users that they would like this too for tables & trees (maybe just for color, I don't really see how a background image would make sense in a table or tree). We should consider allowing end-users to configure this, but this is not the main objective. Maybe we can first do it for specifiers, and add end-user customization later if users request it. * For background color, just specifying a color should be enough. I don't think we need a "transparency" setting for example as this will be in the background anyway. * For images, we probable want to consider different configuration parameters: the size of the image (use its native size, an explicit size, or fit the diagram), how the image should be repeated (if smaller that the view/canvas size), how it should behave with the zoom/scroll (stay fixed or follow the zoom/scroll). * We probably want to support the combination of color + image, with the background color visible through the transparent parts of the image (if any). * In all cases, we'll need to consider if these new background elements should be included when the representation is exported or printed. For diagrams, adding a background should not make the grid invisible/unusable.
Moving to 6.0 for further consideration, but may be dropped.
New Gerrit change created: https://git.eclipse.org/r/114597
New Gerrit change created: https://git.eclipse.org/r/114639
New Gerrit change created: https://git.eclipse.org/r/114691
Created attachment 272076 [details] Sample diagram showing a problem with background refresh Steps to reproduce the problem: 1. Import the attached project. It contains a diagram definition whose background color is interpolated between white and orange depending on how many classes are inside the EPackage. 2. Open the diagram. The background is a very light orange (it contains a single EClass). 3. Create new EClasses using the tool in the palette. After each addition, the background is refreshed and becomes a little darker: OK. 4. Select all but one of the EClasses on the diagram and remove them. The background color is not refreshed back to the previous state: KO. An explicit "Refresh" does not fix the issue. 5. Close and re-open the diagram: the background now corresponds to the current state. In the case where a new EClass is added, we end up calling refresh() (and thus refreshVisuals()) on DDiagramEditPart because of code in AbstractDDiagramEditPart.handleNotificationEvent(Notification), but this is to handle some special cases.
Gerrit change https://git.eclipse.org/r/114639 was merged to [master]. Commit: http://git.eclipse.org/c/sirius/org.eclipse.sirius.git/commit/?id=8e2dccede576215216a8295095cb2160885916b1
Gerrit change https://git.eclipse.org/r/114597 was merged to [master]. Commit: http://git.eclipse.org/c/sirius/org.eclipse.sirius.git/commit/?id=3688e7576d3b1f1cf492ed59a4f0f6ae701b2e55
The main part of the feature is available in Sirius 6.0M5. I'll open a separate ticket for the background image part; not sure when we'll have the resources to finish that. There is a (small) limitation identified in the current version: the code assumes that the default background is pure white (255,255,255) when nothing else is specified, but it seems this is not true depending on the theme used (e.g. when using the dark theme, the diagram background is black). Not sure yet if we'll just live with that (and document the limitation), or try to handle it somehow before closing this ticket.
See https://bugs.eclipse.org/bugs/show_bug.cgi?id=531029 for the background image support.
Available in Sirius 6.0.0, see https://wiki.eclipse.org/Sirius/6.0.0 for details
