Created attachment 43775 [details] Spreadsheet with large row heights showing that scrolling is broken. A spreadsheet with large row heights (e.g. a big description) - even larger than your screen height - should of course still be easy to work with. However for no good reason LibreOffice's scrolling in spreadsheets is designed to snap to rows and this makes it hard - or almost imposslble - to work with spreadsheets with large row heights. Of course scrolling should be like in a webbrowser - natural and smooth - but instead LibreOffice moves in big jumps like a broken mouse. Try scrolling up and down in the attached spreadsheet - and perhaps even type a big amount of text and while typing use the scrollbar to position the text/cursor where you want vertically. It's impossible.
[Reproducible] with "LibreOffice 3.3.1 – WIN7 Home Premium (64bit) German UI [OOO330m19 (build 8 / tag 3.3.1.2)]". Old OOo problem, but I just can't find the corresponding Issue No. <http://openoffice.org/bugzilla/show_bug.cgi?id=81907> Only talks about mouse wheel scrolling Affected is not only vertical, but also horizontal scroll, if you create a column with 50 cm width, you cant do a horizontal scroll the middle of the column. As reporter said, reason is that the first top left cell shown in the spreadsheet always will snap to visible range area, you will never see only a part of the cell at the top or left end of the visible area. I do not know whether there might be good reasons for the current behavior. We have been living with that problem from the beginning of OOo, so it's not a blocker. MS EXCEL VIEWER has the same limitation.
Assigning to Kohei; as always, feel free to assign back to list if you feel having this on your list is not useful. Please add a comment if you have insight in how hard it would be to fix this.
Actually google docs (and, I think, Excell) has the same frustrating problem too. It's interesting that since Microsoft started this trend "everybody" has mimicked it without questioning wether it's good - or - more likely - bad.
(In reply to comment #3) > Actually google docs (and, I think, Excell) has the same frustrating problem > too. > > It's interesting that since Microsoft started this trend "everybody" has > mimicked it without questioning wether it's good - or - more likely - bad. I wouldn't call this "mimicking without questioning" (which I take slight offence with since that implies we developers don't think), but rather it's hard to overcome that given how spreadsheet works. BTW Excel solved this in 2007.
"Bug 40917 - UI: scrolling only by full row height" is not exactly the same issue, but I believe a common solution would be fine.
(In reply to comment #5) > "Bug 40917 - UI: scrolling only by full row height" is not exactly the same > issue, but I believe a common solution would be fine. BTW scrolling by full row height is done for a reason, and it's not practical to solve it without causing other, more serious issues mostly in the performance area. So, don't expect Bug 40917 to be solved anytime soon, if ever.
BTW this is what Anurag Jain's GSOC work - support multi-line formula input bar - aims to resolve. There was a bug filed for that (can't remember the number), and I would say it's more appropriate to mark this as a duplicate of that bug.
*** Bug 41139 has been marked as a duplicate of this bug. ***
Noel is currently looking into the new input bar.
*** Bug 46505 has been marked as a duplicate of this bug. ***
Reproducable on v3.5.5.3 - view still jumps horribly. Also if you have a cell/row heigher than the window with the content vertically aligned to the bottom it's IMPOSSIBLE to see that text since it's ALWAYS outside the screen becuase you can't scroll in steps smaller than the row height. A real showstopper this one.
(In reply to comment #11) > > A real showstopper this one. 'showstopper' really? especially since you say Excel or Google docs do the same thing, its been like this forever etc. etc. I think your scenario is not that common, this hardly this qualifies as a showstopper. Further more as Kohei explained this is by design ( admittedly there is room for improvement ) therefore I am making this an enhancement. Anyway since the new inputbar does allow you to view and edit text that would normally be hidden in this scenario the situation has been improved somewhat. Since the reporter seems not to think the inputbar addresses this issue I am returning this to the pool.
I agree - it's a "showstopper" only in the - admittedly rare - situation where the cell exceeds the window-size. The formular bar I agree makes it possible to see the text after all - not nicely but barely.
*** Bug 114849 has been marked as a duplicate of this bug. ***
*** Bug 84099 has been marked as a duplicate of this bug. ***
*** Bug 70525 has been marked as a duplicate of this bug. ***
Sadly this behaviour is really annoying. Smooth scrolling would be nice. Unfortunately the docs for developers are not very good, I would really like to improve some stuff for LO :( Maybe someone can contact and help me (I use a Mac).
(In reply to lupurus from comment #17) > Sadly this behaviour is really annoying. Smooth scrolling would be nice. > > Unfortunately the docs for developers are not very good, I would really like > to improve some stuff for LO :( Maybe someone can contact and help me (I use > a Mac). A few pointers: https://www.libreoffice.org/community/developers/ https://wiki.documentfoundation.org/Development https://wiki.documentfoundation.org/Development/BuildingOnMac https://docs.libreoffice.org https://opengrok.libreoffice.org (core project)
I checked all the pages, but developing for Mac is so badly documentated. I gave up, because it was too frustrating. Couldn't find out how to create the Xcode-project.
I landed on this page from one of the duplicates. I would like to extend the issue to "Cell with large dimensions make LibreOffice Calc impossible/unpleasant to work with". Issue details: In my daily work I have to deal with CSV and other form of spread sheets that have lengthy texts as the cell values (typically column names) and when I scroll horizontally the jump are as big as the width of the column that just had disappeared! Suggestion: It would be wise to have an option in the preferences to let user choose between "smooth scrolling" and "legacy scrolling". I'll be happy to provide testcase if the explanation I provided is not clear enough. This is a serious issue and it is slightly worrying that it has been almost 8 years since this issue have been reported and yet no tangible action have been taken so far!
An obvious workaround is to zoom out on the sheet. If that reduces legibility too far, then use assorted text function to split the text into different cells nearby, or reformat the cells using wrap etc. as appropriate.
(In reply to Libomark from comment #21) > An obvious workaround is to zoom out on the sheet. If that reduces > legibility too far, then use assorted text function to split the text into > different cells nearby, or reformat the cells using wrap etc. as appropriate. Modifying the layout of the document is not always an option. My most recent occurrence of this issue was updating finding status on a STIG viewer spreadsheet export (which needed to be re-imported into the tool).
(In reply to Mehrad Mahmoudian from comment #20) > Suggestion: > It would be wise to have an option in the preferences to let user choose > between "smooth scrolling" and "legacy scrolling". I totally agree. The current method of scrolling is almost impossible to use on a touchpad and on trackball with button scrolling (Using the modifier button which makes the ball behave as a scroll wheel).
It's still a problem in LibreOffice-6.4.11.
Set back to "Inherited by OOo". Please do not change the version field with a LibreOffice version you see the issue the last time. This field is for the oldest version where this issue was seen.
Made an account to say, I'd really like this bug solved / feature added
(In reply to Ethan from comment #27) > Made an account to say, I'd really like this bug solved / feature added (dunno how to edit a comment). And Calligra Sheets doesn't seem to have this problem
what does it take to fix it? will a donation make a difference?
Related meta: Bug 98754 Current ticket will celebrate 10th anniversary in a week
I'd really like this bug solved / feature added.
Also recently ran into this problem. I have to copy out the contents of the cell into a separate text editor to see everything. I hope this get fixed some time ...
For what it's worth, Excel has the same issue but Microsoft is working on a fix: https://excel.uservoice.com/forums/304921/suggestions/9769824
On Windows builds, the shortcut on the menu entry is just Ctrl, and does toggle the formula <> calculation. But the expected shortcut <Ctrl>+` toggles the view of the cell. (On en-US 102 keyboard that is combined with the ~ key upper left) http://www-look-4.com/ Customize keyboard for Calc or LibreOffice shows no keys assigned to the View -> Show Formula action. Hmm... @Jay? Windows 10 Pro 64-bit (1607) en-US with Version: 5.3.0.0.alpha0+ Build ID: c2b48a763df113e63e6a27ee05b9a6834e4e49a4 http://www.compilatori.com/ CPU Threads: 8; OS Version: Windows 6.2; UI Render: default; TinderBox: Win-x86@62-merge-TDF, Branch:MASTER, Time: 2016-10-20_06:56:44 Locale: en-US (en_US); Calc: CL http://www.wearelondonmade.com/ The show formula uno command (.uno:ToggleFormula) has been assigned[1] to "QUOTELEFT_MOD1" since the OOo days, but i recently added it to the view menu in master. I noticed the shortcut a few days ago when i was in the menu and found it was strange as well to say 'grave'. :D http://www.jopspeech.com/ So i'm assuming we should show the character rather than naming it, like we do with command and semi colon. On Windows builds, the shortcut on the menu entry is just Ctrl, and does toggle the formula <> calculation. http://joerg.li/ But the expected shortcut <Ctrl>+` toggles the view of the cell. (On en-US 102 keyboard that is combined with the ~ key upper left) Customize keyboard for Calc or LibreOffice shows no keys assigned to the View -> Show Formula action. Hmm... http://connstr.net/ @Jay? Windows 10 Pro 64-bit (1607) en-US with Version: 5.3.0.0.alpha0+ Build ID: c2b48a763df113e63e6a27ee05b9a6834e4e49a4 CPU Threads: 8; OS Version: Windows 6.2; UI Render: default; TinderBox: Win-x86@62-merge-TDF, Branch:MASTER, Time: 2016-10-20_06:56:44 Locale: en-US (en_US); Calc: CL http://embermanchester.uk/ The show formula uno command (.uno:ToggleFormula) has been assigned[1] to "QUOTELEFT_MOD1" since the OOo days, but i recently added it to the view menu in master. I noticed the shortcut a few days ago when i was in the menu and found it was strange as well to say 'grave'. :D http://www.slipstone.co.uk/ So i'm assuming we should show the character rather than naming it, like we do with command and semi colon. http://www.logoarts.co.uk/ On Windows builds, the shortcut on the menu entry is just Ctrl, and does toggle the formula <> calculation. But the expected shortcut <Ctrl>+` toggles the view of the cell. (On en-US 102 keyboard that is combined with the ~ key upper left) http://www.acpirateradio.co.uk/ Customize keyboard for Calc or LibreOffice shows no keys assigned to the View -> Show Formula action. Hmm... @Jay? Windows 10 Pro 64-bit (1607) en-US with https://waytowhatsnext.com/ Version: 5.3.0.0.alpha0+ Build ID: c2b48a763df113e63e6a27ee05b9a6834e4e49a4 CPU Threads: 8; OS Version: Windows 6.2; UI Render: default; TinderBox: Win-x86@62-merge-TDF, Branch:MASTER, Time: 2016-10-20_06:56:44 Locale: en-US (en_US); Calc: CL https://www.webb-dev.co.uk/ The show formula uno command (.uno:ToggleFormula) has been assigned[1] to "QUOTELEFT_MOD1" since the OOo days, but i recently added it to the view menu in master. I noticed the shortcut a few days ago when i was in the menu and found it was strange as well to say 'grave'. :D http://www.iu-bloomington.com/ So i'm assuming we should show the character rather than naming it, like we do with command and semi colon.
An incremental scroll (possibly even smooth scrolling) of the active Calc sheet would come at considerable cost to performance. But if implemented as a modal toggle it would make for better UX. Otherwise, from LO 3.5.0 onward (implemented for GSOC 2011) LO Calc provides multi-line edit of the active cell that fully exposes the cell text in the Formula Input bar-regardless of height or width of the containing cell on a Calc sheet. The ScInputBarGroup provides edit engine based manipulation of the cell text. Admittedly, this does not expose image/graphics embedded in a cell for review in the UI, but working with text is fine.
As akkadaya@gmail.com asked more than a year ago in comment #29: Will a donation make a difference? I need the smooth scrolling to use OO Calc on a touch display by elderly people in my business, so I'm financially interested into this feature.
(In reply to Jan Nekvasil from comment #36) > As akkadaya@gmail.com asked more than a year ago in comment #29: Will a > donation make a difference? I need the smooth scrolling to use OO Calc on a > touch display by elderly people in my business, so I'm financially > interested into this feature. Donation will not make a difference, but any group of individuals can pool their money and hire a C++ freelancer to fix any bug in LibreOffice.
Please resolve this issue! It would be much appreciated. Thanks
Still this issue is making my usage of LibreOffice on several projects a living hell. I find it very strange some people try to downplay it, while many have attested to its importance, over a period spanning decades. I can find an OpenOffice ticket all the way from 2002 attesting to the same. https://bz.apache.org/ooo/show_bug.cgi?id=7722 Working on a laptop - a small screen - as I often do these days, makes this even more problematic. MS Excel had the same issue for decades though has meanwhile solved it (using v16 on Mac), so apparently saw the rationale after all. Please give this issue some love!
(In reply to gulpen from comment #39) > Please give this issue some love! We have. Two options for working with wide columns or tall rows. Or with undersized displays. One would be to adjust the sheet scroll from default spreadsheet centric "scroll by cell edge" to a "scroll by screen pixel" and requiring new implementation. The other option was implemented to expose the content of oversize cells to edit engine and UI control via an expandable input window on the FormulaBar (View -> Formula Bar) where you will find a "Expand Formula Bar" and "Collapse Formula Bar" toggle triangle. The collapsed formula bar is one character row in height. The expanded formula bar input window can be dragged as tall as 25 lines. Default is 6 lines, but the UI value is recorded into the spreadsheet on save, so it keeps it handy. For really large cell content (an actual sc formula or text strings), the input window has a vertical scroll to work with the entire cell (up to 64,000 characters IANM). Pixel level scrolling a sheet would be nice to implement, but you already are able to work with cells larger than the display or the app window using the Formula Bar's input window, without having to zoom the sheet out.
The formula bar is helpful only to edit the content of an oversized cell. But it doesn't help navigating/viewing the spread sheet itself. A "scroll by screen pixel" sounds like a difficult change. At the same time, it would not only solve the problem with oversized cells, it would also be an advantage over Microsoft Excel.
I ended up here looking for a solution to the problem of scrolling by cells in Libreoffice Calc, but I see that it is a long-standing issue. It seems incredible to me that in such a long time this has not been resolved. I agree that a scroll-by-pixel option would solve the problem of large cells and make navigation smoother.
(In reply to V Stuart Foote from comment #40) > (In reply to gulpen from comment #39) > > > Please give this issue some love! > > We have. > > Two options for working with wide columns or tall rows. Or with undersized > displays. > > One would be to adjust the sheet scroll from default spreadsheet centric > "scroll by cell edge" to a "scroll by screen pixel" and requiring new > implementation. > > The other option was implemented to expose the content of oversize cells to > edit engine and UI control via an expandable input window on the FormulaBar > (View -> Formula Bar) where you will find a "Expand Formula Bar" and > "Collapse Formula Bar" toggle triangle. > > The collapsed formula bar is one character row in height. The expanded > formula bar input window can be dragged as tall as 25 lines. Default is 6 > lines, but the UI value is recorded into the spreadsheet on save, so it > keeps it handy. For really large cell content (an actual sc formula or text > strings), the input window has a vertical scroll to work with the entire > cell (up to 64,000 characters IANM). > > Pixel level scrolling a sheet would be nice to implement, but you already > are able to work with cells larger than the display or the app window using > the Formula Bar's input window, without having to zoom the sheet out. Where do I go in the github to assist with creating a scroll by pixel implementation?
(In reply to Wil from comment #43) > Where do I go in the github to assist with creating a scroll by pixel > implementation? It's not on Github or Gitlab. Code review is done with "gerrit". You can read more about contributing to LO here https://wiki.documentfoundation.org/Development/GetInvolved
I agree that this is a critical issue.
What needs to be done in order to enable scrolling by pixels as opposed to scrolling by cells?