feat(terra-draw): Rotate drag handle#851
Draft
DanielBoa wants to merge 10 commits into
Draft
Conversation
…s mutate selection
…n of the drag handle position
Owner
|
Hey @DanielBoa - this looks really interesting, I will take a proper look when I get a moment! |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description of Changes
Note: I've not yet added tests or documentation as I'm seeking others input before working on this any further.
Add a handle offset from the top edge of a selected feature which allows for the feature to be rotated without the need for keyboard shortcuts.
terra-draw-rotate-handle-demo.mp4
The linked issue mentions another possible UX, the ability to rotate a feature by moving your mouse close to a coordinate and having the cursor update to communicate that a drag is possible. I think this is nice, however I think this approach of having a bounding box and offset drag handle is preferable (in my particular use case) for two main reasons:
I've tried to follow the patterns I've observed in the
select.mode.tsand it's accompanying "behaviours" when implementing this feature, although as I've mentioned above I've stopped short of making this production ready as I want to gauge the feeling of this UX approach to the problem before working on it anymore.If the greenlight was given to this UX then I think it might make sense to extract the guide bounding box logic I've introduce into another behaviour that could also be used by the
ScaleFeatureBehaviorto attach the scaling handles.Feedback would be greatly appreciated.
Link to Issue
#626
PR Checklist