Community
Participate
Working Groups
Hello at the suggestion of Mons. Céderic Brun (Obeo), I am reporting a bug. The problem: Since Sirius 3.0M6 anchors position shift depending on the image content. Transparents pixels are not considered as being part of the shape giving a cleaner result by default - this holds true for nodes, but not for containers. I have a png-file (a circle), which clearly has a transparent surrounding. When I put in in Sirius 3.1 or Sirius 4.0 edges are not touching the actual border, just the invisible square around it. Mons Brun could reproduce the fact that the behavior is not the same for containers. I would like to kindly ask you of an enhancement regarding containers. My use case: I am creating a tool to model Petri nets, so the Place (Circle) is my container, which contains the Token. That is why it would be really convenient, if edges would touch the actual border of my container. I hope I have provided enough information and I am looking forward to hearing from you. Kind regards, Kolja
Hi Kolja, The current behavior for Nodes with a transparent image is to consider that transparent pixels are not being part of the shape as soon as the Node has no border. This is handled by the AlphaBasedSlidableImageAnchor (created for AirDefaultSizeNodeFigure and AirStyleDefaultSizeNodeFigure). For the container and list case, the situation is a bit more complicated than the node case as list and container have a title area and a content pane. You can have a title border, and the content pane can have different layout kinds (list, compartments, free form). So with this enhancement, if we just add the wanted behavior, this might lead to subnodes displayed in the content pane but out of the rendered image and edges connected to the rendered image and not the bounding box, this would not be consistent. We might need to also configure the layout manager of FreeForm containers to restrict the move of subnodes to the rendered image.
Note: the container/list edit parts use some DefaultSizeNodeFigure/ContainerWithTitleBlockFigure/AbstractGeoShapePloygonFigure which are not currently able to create the AlphaBasedSlidableImageAnchor. Further analysis would be needed to see the impacts and merge/refactoring possibilities. I am not sure that the current implementation of AlphaBasedSlidableImageAnchor is already able to handle the figure hierarchy of the container/list cases: it is slightly different from the node case.
Hi Kojla, this looks like an interesting area to explore but note that it's not yet in the scope of a future release.
