(Methinks someone is perhaps a little too enthusiastic about auto-scrolling.)
Well, I’m sure you’ve all been missing me… and now I’m back you may wonder why
Since the mouse has to travel across the screen to reach the settings (the report bug button, or the console control, etc. etc.), if the canvas is wider that the display port, scrolling will occur* - and it shouldn’t because I am not trying to reach an off-screen part of the canvas. Instant annoyance. (And if the canvas isn’t wider, what would be the point?)
Please could you kill it? (Preferably with fire.)
General Point: if every new “feature” like this absolutely had to be controllable by an option it would a) allow those you think will benefit to benefit b) not afflict others who do not perceive it to be a benefit c) impose a slightly greater overhead on implementation and hence provide a moment to pause and reflect: is this really a good idea?
Of course, one would have to educate users and make the settings very easily accessible and/or provide status indicators of important settings to cue users to change them if unhappy… but on balance preferable from my POV.
A prompt farewell to auto-scroll will also save wear and tear on the CPU transistors and pixel erosion on the screen, and yea, verily, the lamb will lie down with the lion, there will be peace and goodwill among men and hosannas will be sung.
(* unless I remember to “go around” which is the very opposite of a frictionless UI.)
PS I suppose you could dynamically enable auto-scroll with #items_selected>0, so that if I have selected something and might be about to curse over to the settings there was no auto-scroll, but that would be just another epicycle.
UDPATE turns out taking the cursor out of the model area before moving elsewhere doesn’t stop auto-scroll - cursor position detection is being done against the whole screen area, so there isn’t even an annoying workaround. Kill it with fire and throw the ashes out to sea, if you would be so kind.
UPDATE 2 The mouse moves outside the canvas, e.g. into Settings, auto-scroll occurs. And now, if the auto-scroll didn’t reach the edge of the canvas, every subsequent movement of the mouse causes more scrolling. I think a trip to Mordor is now in order - I begin to doubt that ordinary fire would be enough.
UPDATE 3 Maybe, just maybe, it’s actually an implementation bug and the auto-scroll control area has been miss-specified, but if that is the case then I would still rather have just fatter scroll bars.
The only use of auto-scroll is when an item is being dragged (i.e. there is a selection) and the mouse cannot be used to drag and slide a scroll bar at the same time, in which case I am not moving the mouse to reach a control in another area so previous objections would not stand - but since selection was not involved it doesn’t seem like that’s what it was supposed to be doing