-
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
Creation tool uses the wrong location when creating a border node from inner container in a Stack #396
Comments
Analysis: Line 547 in 130c209
On classic mapping (ContainerMapping with FreeForm), But when using a combinaison ContainerMapping{vertical_stack} + ContainerMapping{FreeForm}, layoutData is not found and port is placed on default location (left/top corner). A solution may be to update the behavior of See this method to search the proper location: Line 307 in 130c209
|
Step to reproduce:
|
DRAFT: No fully sure of the impact of added test in the subclasses. Must be verify after merged. Bug: #396
Issue396ProjectSample-v2.zip
|
@mypsycho Thank for your analysis, however I think it will be simpler to do the right processing upstream. That is to say, add the correct "LayoutData", with the correct parent edit part associated with the tool, when creating commands in |
- Constructors of CreationUtil have been improved to directly have LayoutData as parameter instead of location and size. Indeed, the location is relative to the parent edit part and for border nodes, the parent edit part is not systematically the "host" of the called policy. - In NodeCreationEditPolicy, in case of border nodes, the "host edit part" is not systematically considered (to compute the RootLayoutData for example). The correct edit part, a parent of the host, is computed according to the mapping defined in the used tool. Bug: #396
- Constructors of CreationUtil have been improved to directly have LayoutData as parameter instead of location and size. Indeed, the location is relative to the parent edit part and for border nodes, the parent edit part is not systematically the "host" of the called policy. - In NodeCreationEditPolicy, in case of border nodes, the "host edit part" is not systematically considered (to compute the RootLayoutData for example). The correct edit part, a parent of the host, is computed according to the mapping defined in the used tool. Bug: #396
- Constructors of CreationUtil have been improved to directly have LayoutData as parameter instead of location and size. Indeed, the location is relative to the parent edit part and for border nodes, the parent edit part is not systematically the "host" of the called policy. - In NodeCreationEditPolicy, in case of border nodes, the "host edit part" is not systematically considered (to compute the RootLayoutData for example). The correct edit part, a parent of the host, is computed according to the mapping defined in the used tool. Bug: #396
- Constructors of CreationUtil have been improved to directly have LayoutData as parameter instead of location and size. Indeed, the location is relative to the parent edit part and for border nodes, the parent edit part is not systematically the "host" of the called policy. - In NodeCreationEditPolicy, in case of border nodes, the "host edit part" is not systematically considered (to compute the RootLayoutData for example). The correct edit part, a parent of the host, is computed according to the mapping defined in the used tool. Bug: #396
- Constructors of CreationUtil have been improved to directly have LayoutData as parameter instead of location and size. Indeed, the location is relative to the parent edit part and for border nodes, the parent edit part is not systematically the "host" of the called policy. - In NodeCreationEditPolicy, in case of border nodes, the "host edit part" is not systematically considered (to compute the RootLayoutData for example). The correct edit part, a parent of the host, is computed according to the mapping defined in the used tool. Bug: #396
Use case:
It is possible in ContainerMapping to create an inner ContainerMapping using childrenPresentation as ContainerLayout.VERTICAL_STACK.
This designs creates a separation between the title zone and the Free form zone.
In this design, the click zone to create a border node is very limited.
A solution is to add the inner ContainerMapping in extraMappings of the NodeCreation tool.
The issue is, in this configuration, location to create the view of a new element is wrong :
The text was updated successfully, but these errors were encountered: