-
Notifications
You must be signed in to change notification settings - Fork 6
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
Add grab interaction to the ruler #140
Comments
This was a very simple change to implement, and I got it working with only one small bug. There is a bug that this introduced. It seems like when I added the grab/drag interaction, the modelViewTransform was off a bit. On first drag, it would jump to a point a bit down and to the left, like that was its origin, then on reset the ruler goes back there, now where it starts at. After investigating further I began wondering why ISLCRulerNode is set up using composition. All listeners and other pieces are set on // @public - ruler node is never destroyed, no listener disposal necessary
model.rulerPositionProperty.link( function( value ) {
ruler.center = modelViewTransform.modelToViewPosition( value );
} ); I would have expected to see inheritance used instead because basically Here is a patch for the whole switcharoo where I am trying to use
I think for now I will revert and try to just fix the minor change in adding the |
I tracked down the bug. The RulerNode was being set in the view via its The fix I made is less than ideal, but I couldn't figure out a better way currently. I'm removing the Again this is less than ideal. @jessegreenberg would you mind reviewing this and seeing if you can find a better way around this. I'm also happy to talk to better explain the hacky hack I hacked into master right now (even though it is just 2 lines). |
@zepumph, I verified the keyboard interactions for grabbing and moving the ruler. This seems to be working nicely. There are additional details (specific help text and alerts) in the design doc that will support the ruler interaction. I will close this issue and open a new one about help text and alerts, and point you to the correct place in the design doc. However, further work ruler interaction can likely be de-prioritized because there is no ruler in the BASICS sim. |
Sounds good @terracoda. I think it is still important for @jessegreenberg to have a look at the implementation, and some of their oddities, re-opening. |
@jessegreenberg here is light ping on review here, since we are working on the Grab/Drag interaction again, as well as this sim. It would be nice to know what you think about this usage. |
@zepumph, FYI I changed the label of the interaction and design context responses for grab and release. Please see updates in the design doc. This likely doesn't affect much of the custom interaction part, though. |
Verifying mobile A11y gesture for
The ruler sounds good:
But it can get stuck
|
Verifying Keyboard for
Coming along nicely @zepumph. Waiting to test anything further. |
I created #194 through #197 to investigate the above bugs found with gesture mobile a11y. It didn't seem like there were any actionable steps to take for keyboard. From here I would recommend creating new issues for further testing and results, and letting this issue be a review of the grab drag implementation added 8 months ago. |
I guess we will close when the related issues are completed? |
@zepumph I really apologize that it took me so long to review this. The particular point of concern in #140 (comment) (issue around So I am reviewing the GrabDragInteraction usage in ISLCRulerNode. I only noticed one thing. The x value here seems specific to gravity-force-lab, I think it was chosen so that the ruler is between the two masses on start up // Empirically determined values to place the cue above the ruler.
grabCueOptions: {
x: 135,
y: -45
}, Should the cue be center-bottom aligned with the ruler by default and these values be moved to GFL? |
How does that look? |
Looks good to me :-) |
@jessegreenberg anything else here? |
Thanks for the ping - looks good! |
Related to #138, I think we should add grab/drag interaction before adding shortcuts.
The text was updated successfully, but these errors were encountered: