Closed shuyuan-liu closed 2 years ago
Thanks for this. An interesting point.
The autoscroll functionality is quite difficult to get right. I am not even sure we should have it. Since you never have to put components near the edge I deem it low priority - however one thing the Spring Term Draw Block development could look at is how better to do autoscroll.
Also note that you can use a combo of standard whole-app zoom, and draw block zoom (see view menu for both), to make the draw area a larger fraction of the screen, that is strongly recommended. Maybe you just chose that shape to demo this problem.
I will keep this issue open for consideration Spring term and any related comments. If it is actually more of a problem that I currently think I could try for a short-term fix, or (quick) turn off auto-scrolling. I could even make auto-scroll user selectable as a quick feature. let me know.
PS - this is an open source project. If you want to try a quick hack of the relevant code (in src/renderer/sheet.fs pp995-1078 and associated subfunctions I will be happy to merge working PRs.
PS - for auto-scroll to work we want scrolling when components are held stationary at edge of canvas. A fix was added so that when moving away from the edge there was no scrolling. Otherwise you get scrolling on any component drag from catalogue. I can see this flying off the edge thing might be a simple bug. If I can find it easily I will fix it next release - but not very likely since that bit of code is quite complex.
Thanks @tomcl for the quick responses.
I'd love to contribute but I don't have any experience with F# or JS so I probably won't be able to fix it in a short time; I'll try and see if I can get it working though.
I think adding the ability to drag the canvas around with the mouse alone could alleviate this problem (or replace autoscroll altogether), as currently I think we can only use the scroll bars or (shift+) mouse wheel. A few similar programs I've used allow the user to drag the canvas by pressing down the middle mouse button, and personally I find that easier to operate and a bit more intuitive than a scroll bar or a keyboard+mouse combo. What do you think?
Yes. That is an idea, it would have to be something other than normal mouse-drag since that is used to select rectangle. Could be right-click, or shift-click, or as you say middle-button-click - though that is maybe not so nice for most.
I have looked at the code a little. It is definitely a bug but I'm not sure how easy to fix ATM.
I will think about adding a screen mouse-drag next time I do proper development. Note however that you already have two-finger scroll gestures on a touchscreen or touchpad. A better way to go would be to enhance this with pinch-zoom and publicise it. Let me know how that works for you.
Also (this is documented under info->keyboard shortcuts) Ctrl/mouse wheel zooms.
I've fixed the bug in v2.3.2, no more flying off screen.
However possibly we should have some more fluid way to pan the canvas for non-touchpad users.
So I will leave this open till Spring, in case that gets done.
A related feature would be to implement correct gesture-based pinch-to-zoom. This requires a suitable JS package:
https://github.com/pmndrs/use-gesture
Is well maintained and npm published, so it should not be too difficult.
Changed Issue name to reflect what is left to do.
This will be closed for now, since what we have is pretty good. Mouse-based panning would require another key to disambiguate it from drag-to-select. Not sure if worth it, given we have auto-panning at edge.
When the user has picked a component from the Catalogue tab and is about to place it down, the component's symbol floats underneath the mouse and follows it. However if the mouse is moved to the edge of the canvas, Issie tries to autoscroll, but that only works correctly if the mouse keeps moving; if the mouse is stationary at the canvas' edge the component symbol "flies off" that edge of the canvas. I've attached a screen capture to demonstrate. (On Issie v2.3.1)