Community
Participate
Working Groups
Created attachment 245683 [details] Video to explain old and new behavior The goal of this feature is to resize a container to the left, upwards, or both, without modifying the location of contained elements. Currently, as you can see in "containerResize.gif", in the old behavior, the location of contained elements are relative to the container. With the new behavior, enabled by a specific shortcut, the contained elements remain fix.
It would actually be a good idea to make this new behaviour the default one. The fact that contained elements are related to the top left 0,0 position is a technical detail. From what I've seen, the end-user expects the same behaviour for the resize in all 4 directions.
This new behavior will be the default one. The current behavior will remain available with a specific shortcut. Shift, Ctrl and Alt is already used by other GMF behaviors during resize. So we must use a character key. What do you think about 'm' (like move children)?
I have nothing against "m". Another idea... what about "r" for relative? (w.r.t. the position of the contained elements which would remain relative to the resized container?
The corresponding specification is available here: http://git.eclipse.org/c/sirius/org.eclipse.sirius.git/commit/?id=1f4c47e4eb06213abd158194c92dee9ae5bc1ab6
Depending on the selection, hitting an alpha-numeric keys like "m" or "r" can trigger direct edit behavior. Are we sure the proposed shortcuts would not conflict with this behavior?
The illustration in the spec implies this, but it should probably be worded explicitly: "contained elements" include both elements inside a container and bordered nodes. Which brings me to: bordered nodes can occur on plain nodes, but the title of the spec and ticket only talks about "Increase size of a *container*": are nodes with bordered nodes included in this change or not?
As said by Pierre-Charles in comment 5, there is a problem with the character shortcut if the direct edit is enabled for the corresponding resized node. It is possible to press the "m" key after starting the resize but when the resize is done, the name of the resized node is filled with many "m" as long as you don't release the "m" key.
About the shortcut, you're right Pierre-Charles. The only way seems to somehow use a "free" combination with a function key...
The specification has been updated according to comment 5 and comment 6. The new version is here: http://git.eclipse.org/c/sirius/org.eclipse.sirius.git/commit/?id=68cb3c2188444b569059bb3cfb4d596a6318316d
Finally, after several test the retained shortcut (Ctrl+R) is not possible. Indeed in some states, the "Reveal All" command conflicts with this behavior. This can be the case for other shortcuts with "Ctrl+char". The retained solution is to use a function key. F4 does not appear be used by other fonction on diagram.
A fix is available here: https://git.eclipse.org/r/#/c/31040/
Some tests can not be automated (impossible to press a key during drag with SWTBot), so manual tests is needed. For this manual tests, copy the project /org.eclipse.sirius.tests.swtbot/data/unit/portPositionStability/tc-1479 in your workspace and use the diagram diagWithBorderNodeOnNode: 1- Resize "blue" p31 to the left with CTRL key pressed Expected : A doesn't move and B stays at the same y axis location 2- Resize "blue" p31 to the left with CTRL + F3 keys pressed Expected : A stays relative to p31 and B stays at the same y axis location 3- Resize "blue" p32 to the right with CTRL key pressed Expected : C stays at the same y axis location and D doesn't move 4- Resize "blue" p32 to the right with CTRL + F3 keys pressed Expected : C stays at the same y axis location and D stays relative to p32 5- Resize "gray" p31 to the left with CTRL key pressed Expected : green A, blue A and blue B don't move and green B stays at the same y axis location 6- Resize "gray" p31 to the left with CTRL + F3 keys pressed Expected : green A, blue A and blue B stays relative to p31, and green B stays at the same y axis location Make same tests with zoom 50% and zoom 125%, and with ALT and SHIFT keys instead of CTRL The data will be available as the bug 441483 will be resolved.
Fixed through commit http://git.eclipse.org/c/sirius/org.eclipse.sirius.git/commit/?id=384fb01d4306d2709dd3c40d7b19ad2a2bb29ca9
Available in Sirius 2.0.0.
As said in comment 12, the corresponding data is [1], some tests have been adapted and completed for this issue [2]. [1] /org.eclipse.sirius.tests.swtbot/data/unit/portPositionStability/tc-1479/* [2] org.eclipse.sirius.tests.swtbot.ChildrenPositionStabilityAfterParentResizeTest
