Apache OpenOffice (AOO) Bugzilla – Issue 81907
Mouse wheel scrolling jumps
Last modified: 2016-01-11 01:26:46 UTC
The user would expect mouse wheel scrolling to go smooth or one line at the time. This would be logical and user friendly. However Open office 2.3 scrolls one CELL at the time which makes mouse wheel scrolling and even scrollbar scrolling jerky, uncomfortable and hard to use. If you have very large cell heights (like a long text) the page might jump HALF A PAGE making reading of the page really really hard. Pleaes make wheel scrolling and scrollbar scrolling smooth - or at least in steps of 10 point font height/~0,5 cm/0,25 inch. - David
*** Issue 81908 has been marked as a duplicate of this issue. ***
One for requirements. IMHO it's Ok as it is now. What else as a row is a line ? The problem what a line can as high as the screen or even higher is a problem of the spreadsheet designer I think. Frank
Created attachment 48480 [details] bug repro for large cell heights
Created attachment 48481 [details] problem repro for large cell height - unable to see the content
Why shouldn't open office be able to show "bad" spreadsheets properly - even on small screens? If you print out a "bad" spreadsheet og view it in Print preview it looks fine - but in the actual open office calc editor you simply can't see the cell content, scroll through it or even Edit it while seeing it. Remember that "bad" spreadsheets my be scientific research with descriptions and measurement results - spreadsheets might be perfect for that. And - as I know from my work - spreadsheets are perfect for technical manuscripts and localizations with lots of text in different languages (one per columes) and huge cell heights. The whole translation business uses spreadsheets and excel sucks with large cell heights. Why now acknowledge that? Why don't you think it's a problem that open office simply can't let the user see and edit the whole cell if its height is large or the user only has a small screen or a small window for open office? All browsers try to show badly designed websites as good as possible letting the user scroll all over them to help the user see the entire page. Programs are there to help the user - not force the user to act in a certain way. Software is meant to be adjusted to best do what the user wants - it shouldn't be the user that is limited to use the software _only_ the way the programmers could think. Please see the attached scripts for repro. I think you might want to call this a DEFECT after seeing the problems this behavoir causes. Certainly not OK. Perhaps you never made a user tests and examined the users' reactions on this exact functionality. Cheers -- David
Issue confirmed on both : - Linux Intel / amd 64 - Mac OS X Aqua ( m237 + aquavcl04 cws ) And yes, this is probably a design issue. Whom ask ?
+ me on CC
This bug is very annoying me. My laptop resolution is 1280x800 and it's very difficult or impossible to see the end of a big cell that contains a lot of data.... The ideal behavior for me would be the be able to scroll the spreadsheet like a canvas like in Gimp or Photoshop... Something like ALT+ "Mouse 1" could make a "Hand" cursor appears and each XY delta of one pixel moves the spreadsheet with the same amount of pixel. I'm sad to see that this bug is low on priority and planned to be resolved "later". Their was no activity on this bug since 2007!! This is a simple usability problem but it can make user mad enough to consider wining MSOffice. OpenOffice 3.0 is very nice and much better than 2.3 but I hope that those little "cracks" here and their could be fixed rapidly to put OO ahead of MS Office... Thanks
@pylanglois FYI, a student form Seneca College started working on that for his semester application. For further information, please look at : http://wiki.services.openoffice.org/wiki/Education_Project/Effort#Fix_MouseWheel_jump_in_Calc_.28cli ck_me.29 and http://wiki.services.openoffice.org/wiki/Education_Project/Effort/Fix_Mousewheel_Jump_in_Calc Please be patient, thanks.
Hi Eric, Thanks for the fast follow up! It seems that MSExcel has the same issue! Happy to see that OOo will be improved! Great software by the way. PYL
No news from the developpers? All of this sounds like "wrong hopes"... Should we wait for this function is implemented in Excel before this query is seriously taken in account?... I think so.
This bug has been "NEW" for 3 years... Is there any possibility for that function is implemented one day? Did the student from Seneca College experiment particular problems? It's a pity that no more information is shared about this issue.
@tontonmanu Good luck! ;)
@tontonmanu : To my knowledge, there is no student form Seneca working on that at the moment. This means the topic is open, and if you are interested, you are welcome to contribute, e.g. providing patches or whatever equivalent. Please remember that I'm working for free (I'm not paid), and I can't do more, but if you can provide a couple student + prof (both with C++ knowledge), then I think it should be possible to drive them for fixing the issue. Off topic : discussing about old bugs, and for the record, this summer, I managed two students, as mentor for the Google Summer of Code, and we did a lot on the starmath improvement. This includes fixing the 9 years bug of the misaligned baseline in OOo (Equation editor) ;-) Thanks
Hi Eric, How can I get involved about this particular issue? I don't say I can solve it shortly but if I can help, I am ready to give it a try. One thing is sure, I can code c++ very well (says the humble guy :)). thanks
@ericb Unfortunately, I've got no knowledge in C++; I'm a "simple user", and I give you my feeling because I use OpenOffice everyday and I enjoy it. I don't blame you for this long waiting, I'm aware of the difficults that such an important project represents. Now, it's a good thing that you say that the study is stopped, we know that the project is waiting for coders. I think we've got here a real possibility of innovating in spreadsheets work - not to say 'in comparison with another spreadsheets program' ;) All that makes OpenOffice different and more user-friendly than other programs makes its popularity. ...And it's alway a pleasure to say to MS users "I've done this with OpenOffice, you can't do the same with MS Office" ;b
It doesn't jump around as much in OpenOffice 4.0, but I noticed it's still not "smooth" it seems to have two speeds: 1 row per second (slow), or 5,000+ rows per second (impossible to control). Definitely not overly smooth.. but it's likely better than it was when this bug was opened. Here's hoping for a smoother scroll.
(In reply to webassistant5.tft+openoffice from comment #17) > It doesn't jump around as much in OpenOffice 4.0, but I noticed it's still > not "smooth" it seems to have two speeds: 1 row per second (slow), or 5,000+ > rows per second (impossible to control). Definitely not overly smooth.. but > it's likely better than it was when this bug was opened. Here's hoping for a > smoother scroll. I see regular scrolling still jumps a bit. I was referring to smooth scrolling (middle mouse button). Both need a slight bit of improvement.
It would be really nice if scrolling could be done on a per-pixel basis instead of a per-cell basis. "X cells per click of the scrollwheel" only makes sense when you have a clicking scrollwheel. Touchpad- or touchscreen-scrolling is much smoother, and generally works best if the displacement of the document is linearly dependent on the displacement of the finger(s). Even with a scrollwheel I feel that the displacement of the document (in pixels, or centimeters) should be a constant. In the current situation, the speed of scrolling is depending on the height of the rows. If you have a mix of taller and shorter rows, a continuous scrolling motion causes a non-continous displacement of the document. A table in a OOo Write document can be scrolled through in a row-height-independent way. The same goes for a table in a HTML document when viewed in a browser. I think that the behaviour in OOo Calc shouldn't be any different.
The scrolling problem on calc has been open for several years. What specific skill is needed to solve the problem ? Programming, coding? Make recommendations, then we can try to find a person willing to voluntarily work and solve this problem.
Created attachment 85246 [details] Separating Row and Cell Height There is a workaround. Don't make very tall cells by making rows higher. Make the cells tall by doing a merge cells on rows of reasonable heights. The same idea applies to horizontal scrolling also. The scrolling will still be by rows/columns, but the ability to see into and navigate within the large cell should be improved. Where this is workable, based on what the actual usage is, it should provide enough user control. This upload illustrates a solution on the first example, 48480. Note that this procedure works when large cells are not in adjacent columns of the same rows and in other cases. This might not be suitable all of the time, depending on how the cell contents are obtained. I hope it will help in some cases.