Bug 34689 - UI scroll problem: Cell with dimensions exceeding screen dimensions impossible to work with
Summary: UI scroll problem: Cell with dimensions exceeding screen dimensions impossibl...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All All
: medium enhancement
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
: 41139 46505 70525 84099 114849 (view as bug list)
Depends on:
Blocks: Calc-UX Calc-Cells
  Show dependency treegraph
 
Reported: 2011-02-24 19:10 UTC by Dakov
Modified: 2019-05-05 11:52 UTC (History)
15 users (show)

See Also:
Crash report or crash signature:


Attachments
Spreadsheet with large row heights showing that scrolling is broken. (7.16 KB, application/vnd.oasis.opendocument.spreadsheet)
2011-02-24 19:10 UTC, Dakov
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Dakov 2011-02-24 19:10:33 UTC
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.
Comment 1 Rainer Bielefeld Retired 2011-02-26 01:22:52 UTC
[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.
Comment 2 Don't use this account, use tml@iki.fi 2011-03-08 00:27:12 UTC
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.
Comment 3 Dakov 2011-03-08 01:45:38 UTC
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.
Comment 4 Kohei Yoshida 2011-03-08 05:26:28 UTC
(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.
Comment 5 Rainer Bielefeld Retired 2011-09-21 01:48:51 UTC
"Bug 40917 - UI: scrolling only by full row height" is not exactly the same issue, but I believe a common solution would be fine.
Comment 6 Kohei Yoshida 2011-09-21 06:37:41 UTC
(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.
Comment 7 Kohei Yoshida 2011-09-21 06:39:19 UTC
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.
Comment 8 Rainer Bielefeld Retired 2011-09-24 00:44:25 UTC
*** Bug 41139 has been marked as a duplicate of this bug. ***
Comment 9 Kohei Yoshida 2011-11-30 14:16:50 UTC
Noel is currently looking into the new input bar.
Comment 10 Rainer Bielefeld Retired 2012-03-20 05:47:17 UTC
*** Bug 46505 has been marked as a duplicate of this bug. ***
Comment 11 Dakov 2012-08-14 14:20:20 UTC
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.
Comment 12 Noel Power 2012-08-15 08:29:33 UTC
(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.
Comment 13 Dakov 2012-08-15 09:34:09 UTC
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.
Comment 14 Buovjaga 2018-01-29 17:23:53 UTC
*** Bug 114849 has been marked as a duplicate of this bug. ***
Comment 15 Nate Graham 2018-08-28 22:03:49 UTC
*** Bug 84099 has been marked as a duplicate of this bug. ***
Comment 16 Olivier Tilloy 2018-09-18 12:52:06 UTC
*** Bug 70525 has been marked as a duplicate of this bug. ***
Comment 17 lupurus 2018-11-10 10:21:57 UTC
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).
Comment 18 Telesto 2018-11-10 10:36:01 UTC
(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)
Comment 19 lupurus 2018-12-13 23:14:32 UTC
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.
Comment 20 Mehrad Mahmoudian 2019-01-15 11:58:54 UTC
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!
Comment 21 Libomark 2019-01-18 19:25:17 UTC
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.
Comment 22 Kyle Marek 2019-01-19 01:57:21 UTC
(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).