Description: When we quickly want to drag and drop, for example, text or an image in a spreadsheet, we immediately know in which cell we want to drop it. Therefore, we do not want the cell we are looking at to scroll when we hover over spreadsheet window. Steps to Reproduce: 1) CALC and web browser windows are side by side (CALC - left, WWW - right. Windows do not overlap). 2) Drag but do not drop from the right side of e.g. a link. 3) After smoothly entering the window, the spreadsheet view shifted. Actual Results: . Expected Results: I would expect the spreadsheet view to not move after smoothly moving content to the CALC window. Only after stopping with the content on one of the pages of the sheet, I would expect the content scrolling to be activated. Reproducible: Always User Profile Reset: No Additional Info: .
Created attachment 182579 [details] 1 Unwanted movement of a spreadsheet after smoothly sliding into the CALC window Actually this movement takes place from any direction. Whichever side you hover over the spreadsheet area, it will be scrolled to that side. As shown in the following videos: 1b 1c 1d
Created attachment 182580 [details] 1b From the top
Created attachment 182581 [details] 1c From the right
Created attachment 182582 [details] 1d From the bottom
(In reply to Piotr Osada from comment #1) > Created attachment 182579 [details] > 1 Unwanted movement of a spreadsheet after smoothly sliding into the CALC > window > > Actually this movement takes place from any direction. Issue #1 So, in my opinion, for a better use of LO, the operation should be changed so that a straight smooth movement does not activate the scrolling function after hovering over the edge of the spreadsheet area.
Created attachment 182583 [details] 2 Non-smooth scrolling, jamming, disproportionate acceleration Issue #2 The second suggestion is to redesign in some way the action of moving the spreadsheet in a certain direction when the cursor hovers over the edge of the spreadsheet area. As it stands, this function is clunky to me. That is, I never know how far I will get by "waiting" with the cursor on the edge. I would see this function designed to accommodate a wide range of motion acceleration: 1) Stopping the cursor stationary at the edge. --> I think here a better behavior than stopping scrolling would be to scroll, for example, at a rate of one cell per 0.5 seconds (or some other well-responsive time that would be long enough to feel like you have control over the movement. Not only for smart MMO RPG players, but also for old grandparents xD). 2) Moving the mouse near the edge of the spreadsheet area. --> It would be convenient to be able to scroll the spreadsheet at a speed of, say, 2 cells per second, up to 10,000 cells per second, depending on how fast you "shake" the cursor in that area. Re. 2) But probably more important and useful than scrolling speed ranges from the point of view of convenience would be to detect the ends of the data ranges with which the cells are filled. That is, if we have values from row #1 to 1234, then if we scroll it would be good if the scrolling stopped at the end of that range (e.g. row 1234 + 1 row for aesthetic separation). And then it would stop at subsequent areas filled with data. Sort of like a pull to filled cells. To make it easier to digest at the beginning and end of the data area.
Created attachment 182584 [details] 3 When another application window overlaps the CALC window and when it does not overlap Issue #3 And there is a different behavior because of the way to reach the spreadsheet area. If there is another window above the CALC window, then when we "fall" onto the CALC window, the spreadsheet does not move. However, when the windows do not overlap, then hovering over CALC causes the sheet to be moved.
I can see how this unwanted scrolling is an annoyance. I don't know how possible it is to block that while dragging onto the canvas but allow it again once the user goes back towards the edges. Copying UX in for their opinion.
The function does not scroll as scrolling (via the scrollbar) but puts the active cell into focus. So if you drag from right you tell the application to bring this cell into the view plus preparing to move further. It is a desired functionality. To solve the problem I could imagine a timer which prevents scrolling for something like 500ms. And to make the scrolling smoother, we could infinitely scroll if the cursor is on the edge (one has to move the cursor to drop). Eike, what do you think?
Created attachment 184918 [details] 4 Scrolling areas and speed functions.png How about scrolling areas that are on drawing? Proposition: speed of scrolling determined by vicinity of the cursor to the scrollbar (and/or speed of moving the cursor in "scrolling area").
Thanks Piotr for the speed idea. Together with a timer that blocks immediate scrolling the user experience should improve.