If I have spreadsheet document with large, multiline cells, I can't scroll to distance equal some part of line. full line is scrolled at once. There is no option in preferences about scrolling by line (as in Excel) and scrolling by pixels (as in Word). Please add such option, or tell me where to find it, if it exists. The original from: (https://bugs.launchpad.net/ubuntu/+source/openoffice.org/+bug/375395)
I believe this is more or less a DUP of "Bug 34689 - UI scroll problem: Cell with dimensions exceeding screen dimensions impossible to work with". @Коренберг Марк: Do you agree? Please file Bug reports with status UNCONFIRMED if your are not absolutely sure that it's not a DUPlicate, that you contributed all required background information, that the problem will be reproducible with information you can provide or that your enhancement request will be accepted! Thank you! May be you can test <http://wiki.documentfoundation.org/BugReport_Details> for submitting bug reports?
Yes, this two bugs are connected. But they are different. My bug specify that scrolling is always jumpy. Bug 34689 is in impossibility to scroll large cells. If smooth scrolling will be implemented, both bugs will be closed. Closing Bug 34689 may be implemented in another way.
[This is an automated message.] This bug was filed before the changes to Bugzilla on 2011-10-16. Thus it started right out as NEW without ever being explicitly confirmed. The bug is changed to state NEEDINFO for this reason. To move this bug from NEEDINFO back to NEW please check if the bug still persists with the 3.5.0 beta1 or beta2 prereleases. Details on how to test the 3.5.0 beta1 can be found at: http://wiki.documentfoundation.org/QA/BugHunting_Session_3.5.0.-1 more detail on this bulk operation: http://nabble.documentfoundation.org/RFC-Operation-Spamzilla-tp3607474p3607474.html
needinfo keyword redundant by needinfo status.
Dear bug submitter! Due to the fact, that there are a lot of NEEDINFO bugs with no answer within the last six months, we close all of these bugs. To keep this message short, more infos are available @ https://wiki.documentfoundation.org/QA/NeedinfoClosure#Statement Thanks for understanding and hopefully updating your bug, so that everything is prepared for developers to fix your problem. Yours! Florian
Confirmed that the problem is still present with Calc 5.3.2.2. Scrolling by whole lines is jarring and unnatural. And as mentioned, implementing proper pixel-by-pixel scrolling will also resolve https://bugs.documentfoundation.org//show_bug.cgi?id=34689.
*** Bug 98755 has been marked as a duplicate of this bug. ***
set status to NEW since there's an independent confirmation in comment 9
*** Bug 125098 has been marked as a duplicate of this bug. ***
*** Bug 35759 has been marked as a duplicate of this bug. ***
From 3.5.0 builds onward, the multi-line input for the Formula Input Bar (ScInputBarGroup) provides direct editing of a an over height cell including cursor and page movements (provided by the edit engine) IMHO resolving bug 34689. So yes, the Calc sheet rendered to VCL canvas only scrolls by single sheet rows. Note also that the provided scroll bar control (up, down, and thumb slide) also move in full row increments. IIUC more precise/incremental scrolling has been necessary because the entire sheet is the extend of the scroll, millions of cells-thousands of columns and rows. Contrasted to Writer tables, which provide precise/incremental scrolling (and smooth scrolling) Calc sheets are much more complex. Rendering them for more precise scrolling seems desirable but likely non-performant if the entire sheet is being manipulated. Meaning there would need to be a new view shell framework to allow off screen caching of a view port onto the sheet--controlled by the range of visible/working cells. Complex stuff, and requires major refactoring of Calc needing some UX envisioning. But the refactoring (to support some semblance of view ports into a sheet) may be too much for a GSOC project.
(In reply to V Stuart Foote from comment #14) Sorry, unclear > IIUC more precise/incremental scrolling has been necessary because the > entire sheet is the extend of the scroll, millions of cells-thousands of > columns and rows. > rather, more precise/incremental scrolling has been impossible because the entire sheet is the extent of the scroll...
*** Bug 95920 has been marked as a duplicate of this bug. ***
*** Bug 117487 has been marked as a duplicate of this bug. ***
*** Bug 114849 has been marked as a duplicate of this bug. ***
(In reply to V Stuart Foote from comment #14) > Complex stuff, and requires major refactoring of Calc needing some UX > envisioning. What exactly? The requirement is clear (and requested repeatedly in the recent survey [1]). It's expected to scroll per pixel even when the cell exceeds the window size. We have to jump to the top when going into edit mode. But besides I don't see nothing controversial. [1] https://design.blog.documentfoundation.org/2021/10/18/results-from-the-survey-about-libreoffice-calc/
*** Bug 149618 has been marked as a duplicate of this bug. ***
*** Bug 149869 has been marked as a duplicate of this bug. ***
*** Bug 152566 has been marked as a duplicate of this bug. ***
*** Bug 163172 has been marked as a duplicate of this bug. ***