-
Notifications
You must be signed in to change notification settings - Fork 11
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
The internal method GMFHelper.getAbsoluteBounds(Node) can be improved for containers with auto-size #426
Comments
The above examples can be used as starting point to check the results. The corresponding project is here: Issue426-ProjectSample.zip. |
Several points are handled in this commit. It should maybe split in several commit to facilitate reviewing... * Border nodes are wrongly considered in GMFHelper.getBottomRight Because of typo, the border nodes are considered in org.eclipse.sirius.diagram.ui.internal.refresh.GMFHelper.getBottomRight(Node) when they should be ignored. * Other cases to details Bug: #426
Because of typo, the border nodes are considered in org.eclipse.sirius.diagram.ui.internal.refresh.GMFHelper.getBottomRight(Node) when they should be ignored. Bug: #426
* Add method getBottomRightInsets to use it in auto-size computation * Consider shadow border * Consider border nodes when computing children bottom-right corner. Bug: #426
This compartment is an intermediate GMF Node and should not have the same behavior when computing auto-size: - Minimal size defined by ResizableCompartmentFigure.MIN_CLIENT_DP - No shadow border Bug: #426
Before this commit, this kind of container was not correctly handled. Bug: #426
Before this commit, this kind of container was not correctly handled. Bug: #426
Because of typo, the border nodes are considered in org.eclipse.sirius.diagram.ui.internal.refresh.GMFHelper.getBottomRight(Node) when they should be ignored. Bug: #426
* Add method getBottomRightInsets to use it in auto-size computation * Consider shadow border * Consider border nodes when computing children bottom-right corner. Bug: #426
This compartment is an intermediate GMF Node and should not have the same behavior when computing auto-size: - Minimal size defined by ResizableCompartmentFigure.MIN_CLIENT_DP - No shadow border Bug: #426
Before this commit, this kind of container was not correctly handled. Bug: #426
Before this commit, this kind of container was not correctly handled. Bug: #426
Before this commit, this kind of container was not correctly handled. Bug: #426
Because of typo, the border nodes are considered in org.eclipse.sirius.diagram.ui.internal.refresh.GMFHelper.getBottomRight(Node) when they should be ignored. Bug: #426
* Add method getBottomRightInsets to use it in auto-size computation * Consider shadow border * Consider border nodes when computing children bottom-right corner. Bug: #426
This compartment is an intermediate GMF Node and should not have the same behavior when computing auto-size: - Minimal size defined by ResizableCompartmentFigure.MIN_CLIENT_DP - No shadow border Bug: #426
Before this commit, this kind of container was not correctly handled. Bug: #426
The code will be more logic with this refactoring and facilitate the following changes. Bug: #426
This compartment is an intermediate GMF Node and should not have the same behavior when computing auto-size: - Minimal size defined by ResizableCompartmentFigure.MIN_CLIENT_DP - No shadow border Bug: #426
Before this commit, this kind of container was not correctly handled. Bug: #426
Before this commit, this kind of container was not correctly handled. Bug: #426
Before this commit, this kind of container was not correctly handled. Bug: #426
This test was based on some wrong bounds. The edge has been slightly moved to retrieve the previous edge bendpoints number after collapse. Bug: #426
The bounds for a node can be computed several times for a parent or a child bounds calculation. This commit adds a cache to avoid computing it again. Bug: #426
Analysis: It seems that before, the code with comment "manage location of bordered node with closest side", in GMFHelper.getAbsoluteLocation, is called only in specific circumstances. Since recent changes, it was called systematically, but that shouldn't be the case. This commit also reduces the number of getAbsoluBounds methods to ease the impact analysis. Bug: #426
The bounds for a node can be computed several times for a parent or a child bounds calculation. This commit adds a cache to avoid computing it again. Bug: #426
Analysis: It seems that before, the code with comment "manage location of bordered node with closest side", in GMFHelper.getAbsoluteLocation, is called only in specific circumstances. Since recent changes, it was called systematically, but that shouldn't be the case. This commit also reduces the number of getAbsoluBounds methods to ease the impact analysis. Bug: #426
Analysis: It seems that before, the code with comment "manage location of bordered node with closest side", in GMFHelper.getAbsoluteLocation, is called only in specific circumstances. Since recent changes, it was called systematically, but that shouldn't be the case. This commit also reduces the number of getAbsoluBounds methods to ease the impact analysis. Bug: #426
After several checks, the PR #427 is now OK to be reviewed. |
Analysis: It seems that before, the code with comment "manage location of bordered node with closest side", in GMFHelper.getAbsoluteLocation, is called only in specific circumstances. Since recent changes, it was called systematically, but that shouldn't be the case. This commit also reduces the number of getAbsoluBounds methods to ease the impact analysis. Bug: #426
Because of typo, the border nodes are considered in org.eclipse.sirius.diagram.ui.internal.refresh.GMFHelper.getBottomRight(Node) when they should be ignored. Bug: #426
* Add method getBottomRightInsets to use it in auto-size computation * Consider shadow border * Consider border nodes when computing children bottom-right corner. Bug: #426
The code will be more logic with this refactoring and facilitate the following changes. Bug: #426
This compartment is an intermediate GMF Node and should not have the same behavior when computing auto-size: - Minimal size defined by ResizableCompartmentFigure.MIN_CLIENT_DP - No shadow border Bug: #426
Before this commit, this kind of container was not correctly handled. Bug: #426
Before this commit, this kind of container was not correctly handled. Bug: #426
Before this commit, this kind of container was not correctly handled. Bug: #426
This test was based on some wrong bounds. The edge has been slightly moved to retrieve the previous edge bendpoints number after collapse. Bug: #426
The bounds for a node can be computed several times for a parent or a child bounds calculation. This commit adds a cache to avoid computing it again. Bug: #426
Analysis: It seems that before, the code with comment "manage location of bordered node with closest side", in GMFHelper.getAbsoluteLocation, is called only in specific circumstances. Since recent changes, it was called systematically, but that shouldn't be the case. This commit also reduces the number of getAbsoluBounds methods to ease the impact analysis. Bug: #426
As a reminder, this method attempts to calculate, based on the GMF data, a dimension as close as possible to the dimension that the corresponding Draw2D figure will have.
In several cases, the result is false. This method is used, for example, in the Debug view.
Here are some samples. They should probably be completed with list containers and, Vertical or Horizontal Stack containers.
The text was updated successfully, but these errors were encountered: