Haven't seen this raised before, but I was wondering if it was possible to consider a change to the way moving tokens is handled when the snap to grid is on.
Instead of instantly snapping to grid as the token is moved, which can make moving tokens a little difficult, is it possible to move the counter as if it wasn't snapped to grid and only then snap to grid when the counter is 'let go'?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Maybe it's just me, but once I've grabbed the token it often jumps about a bit until you get a feel for where the mouse cursor now is. It's as if the point of the mouse cursor has moved a little off where I expected to be. Often when you grab the token the smallest movement on the mouse will make the token jump upwards one square, even if you move the mouse left or right. Maybe it's my system, but it always does it.
Moving the token smoothly (as it does with the snap to grid off) seems much more less clunky (at least to me).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hmmm, sounds like a bug in the drag code. If it didn't jump immediately would that work out ok ?
Having it jump while dragging has the advantage that you always know where it will drop to. If it snaps when you drop, you might drop in a square that wasn't intended.
Another possible option is to make the destination cell highlight somehow to indicate drag-target, that would allow dragging smooth but still know where you would drop. But that might be a post 1.0 feature.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yes, I can understand the problem of accidently dropping the token in the wrong square, however this is reduced because the breadcrumbs (and right-click waypoints) would still display, effectively showing you which square the programme thinks the token is currently 'in'. Displaying the bread crumbs on top of the token (rather than letting the token obscure the bread crumb) would help further. Feasible?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Haven't seen this raised before, but I was wondering if it was possible to consider a change to the way moving tokens is handled when the snap to grid is on.
Instead of instantly snapping to grid as the token is moved, which can make moving tokens a little difficult, is it possible to move the counter as if it wasn't snapped to grid and only then snap to grid when the counter is 'let go'?
It's certainly possible, tell me more about what makes 'moving tokens a little difficult' so that I can understand where you are coming from?
Maybe it's just me, but once I've grabbed the token it often jumps about a bit until you get a feel for where the mouse cursor now is. It's as if the point of the mouse cursor has moved a little off where I expected to be. Often when you grab the token the smallest movement on the mouse will make the token jump upwards one square, even if you move the mouse left or right. Maybe it's my system, but it always does it.
Moving the token smoothly (as it does with the snap to grid off) seems much more less clunky (at least to me).
Hmmm, sounds like a bug in the drag code. If it didn't jump immediately would that work out ok ?
Having it jump while dragging has the advantage that you always know where it will drop to. If it snaps when you drop, you might drop in a square that wasn't intended.
Another possible option is to make the destination cell highlight somehow to indicate drag-target, that would allow dragging smooth but still know where you would drop. But that might be a post 1.0 feature.
Yes, I can understand the problem of accidently dropping the token in the wrong square, however this is reduced because the breadcrumbs (and right-click waypoints) would still display, effectively showing you which square the programme thinks the token is currently 'in'. Displaying the bread crumbs on top of the token (rather than letting the token obscure the bread crumb) would help further. Feasible?
Let me play with it a bit to understand it a bit better, talk with some of the others, and see what we can come up with :)
Cheers!