Skip to content
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

[359] New implementation of move with arrow keys #360

Merged
merged 5 commits into from
Apr 29, 2024

Conversation

lredor
Copy link
Contributor

@lredor lredor commented Apr 17, 2024

Bug: #359

@lredor

This comment was marked as outdated.

@lredor lredor force-pushed the bug/lre/359-moveFromKeyboard branch 4 times, most recently from fb7d07d to 0555db3 Compare April 19, 2024 20:06
@lredor lredor force-pushed the bug/lre/359-moveFromKeyboard branch 2 times, most recently from 06dc15e to 6f99363 Compare April 26, 2024 07:39
@scosta-obeo scosta-obeo self-requested a review April 26, 2024 13:16
Copy link
Contributor

@scosta-obeo scosta-obeo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If the mouse cursor leave the diagram frame during the "arrow key movement" (i.e. the node is selected, the arrow key is pressed and we can see the "helper result ghost" (the grey rectangle indicates where the element will be moved if the key is released)), the movement starts again from its point of departure. See attached video 2024-04-26 15-44-28.zip (inside zip file)

lredor added 5 commits April 26, 2024 17:59
This commit only updates the data used by SnapAllShapesTest without any
change (except the migration).
The test org.eclipse.sirius.tests.swtbot.SnapAllShapesTest.testMoveBorderNodeOnNodeInContainer()
has been updated. It wrongly used the same border nodes as
"testMoveBorderNodeOnBorderNode()". This case has been detected because
the new test class MoveAllShapesWithArrowKeysTest is inspired by this
one.
This commit changes the CheckBoundsCondition to also be able to consider
the HandleBounds figure and the scrollbars.

A rounding problem has been detected in GraphicalHelper and fixed during
these tests.

Bug: #359
This commit disables the snap to the perpendicular axis of the arrow
direction. Indeed, if the user moves a node in the left direction, for
example, it doesn't want to see its node moves up or down too.

The tests have also been adapted.

Bug: #359
@lredor lredor force-pushed the bug/lre/359-moveFromKeyboard branch from 6f99363 to 3ed7653 Compare April 26, 2024 16:00
@lredor
Copy link
Contributor Author

lredor commented Apr 26, 2024

If the mouse cursor leave the diagram frame during the "arrow key movement" (i.e. the node is selected, the arrow key is pressed and we can see the "helper result ghost" (the grey rectangle indicates where the element will be moved if the key is released)), the movement starts again from its point of departure. See attached video 2024-04-26 15-44-28.zip (inside zip file)

Good catch! I'll add specific code in org.eclipse.sirius.diagram.ui.tools.internal.palette.SiriusSelectionToolEx.handleViewerExited() to handle this case in the next PR version.

@lredor lredor added this to the v7.4.1 milestone Apr 26, 2024
@lredor lredor requested a review from scosta-obeo April 26, 2024 16:01
@lredor lredor merged commit 161d20e into master Apr 29, 2024
2 checks passed
@lredor lredor deleted the bug/lre/359-moveFromKeyboard branch April 29, 2024 14:58
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants