GNOME Bugzilla – Bug 170871
Improve scrolling behaviour and track current location
Last modified: 2018-05-22 12:55:50 UTC
In bug 165120 Emil was cool enough to get us spacebar scrolling in Evince. However this is only the begining ;-) I created a mockup to demostrate what I'm talking about here. http://gnome.org/~clarkbw/designs/document-viewer/sweet%20spacebar%20scroll.gif We need to smooth out the scrolling action instead of snapping the view. To help out with visual tracking of the scroll area we can overlay an image that gives a visual cue of what area of the page will be scrolled away. Same can be done for the reverse.
Isn't GTK+ going to provide smooth scrolling sometime in the future?
Bryan, how does this compare to smooth scrolling?
I'm not sure how this compares to smooth scrolling. Perhaps we can use smooth scrolling to do part of this. The real idea here is to do the shading part. I made the shading pretty dark so that it's obvious, we'd want to implement a lighter shade. It's meant to help a person visually track the document as it moves. The shading quickly marks where the text will be hidden / visible and then the text is scrolled.
But like the progress notification, this is the kind of thing you wouldn't want happening when you're just running through the pages quickly or you'll get lots of flashing.
Created attachment 51745 [details] [review] The patch This patch animates the scrolling you get when you use the mouse wheel. It's kinda slow though, at least with my video driver. It's probably not committable yet ...
(and in case it wasn't clear: it doesn't do any shading)
Created attachment 52550 [details] [review] Just updated this patch to CVS HEAD
could it be like: * space bar "click" -> time between press and release below treshold it does the scrolling like Bryan suggests (with shading and all) * space bar "hold" (release timeout) -> while i hold space it scrolls smoothly (maybe slowly accelerating until some sane "full speed") as soon as i released space it abruptly stops.
*** Bug 341566 has been marked as a duplicate of this bug. ***
You can avoid interference when you're running through pages fast by showing it only if requests for scrolling are separated by a long enough time.
Also, drawing a line instead of shading will probably work better for old video cards.
*** Bug 540288 has been marked as a duplicate of this bug. ***
*** Bug 553275 has been marked as a duplicate of this bug. ***
I would like to suggest another solution, adding to what Philip's comment #11, in the case of instant (non-smooth) scrolling. Let's call the part of the document that touches the bottom edge of the viewport the "boundary line". Right after instant non-smooth scrolling finishes, we briefly flash the boundary line to let the user know where to continue reading. Another approach is to instantly darken the part of the document before the "context-line" and then gradually fade it back in over one second or less. This second approach differs from the gif in that this one involves instant scrolling.
I see that this has been marked as an enhancement, but as somebody who uses evince for document reading on a daily basis, I want to second the opinion on bug 553275 that says that this bug makes reading a tiresome process. That bug, which was marked as a duplicate of this one notes that when you scroll with space bar or page up/down, it doesn't scroll an entire page. It scrolls around 70% of the page, and you have to reorient yourself to where you left off before you scrolled. It's a real problem for usability that makes evince very difficult to use. I wonder if we can up the priority of this bug or mark that one as not a duplicate, since they are addressing similar but different problems. I also worry that since the solution proposed here seems programmatically more challenging than the solution needed with the 70% scroll problem, if that means that the 70% scroll problem isn't going to be fixed any time soon.
I'm sorry to come back and post yet another comment on this thread, but there hasn't been any response on my last comment since 3-12, nor does there seem to be any development being done to fix this bug. I know this is a volunteer project, and I wish I were able to fix it myself, but I still wonder if there is anything that can be done to get this bug a higher priority. Maybe I do more reading with evince than most other people, but this scrolling malfunction is really quite difficult to work with when reading. Here's a screenshot of what I've started doing to cope with it until this bug is fixed. Essentially, I've set up a terminal with "Always on top" status so that it blocks off the bottom of the screen in evince, thus serving as a horizontal ruler while I'm reading. Users shouldn't have to do this, right?
Created attachment 131605 [details] Demonstrating the hack I've developed to make evince usable.
It's been almost six months since I last commented on this bug, and this bug has been unresolved for four and a half YEARS! Reading over it one more time, I'm unsure developers are actually aware of what the problem is. It sounds like people are proposing that this be fixed by implementing some kind of smooth-scrolling. The problem however, is that pressing space bar or page-down only scrolls about 70% of the screen, rather than 100%. Fixing that would go a LONG ways towards improving context tracking on scroll. I'd love to work on this bug if I had the knowledge (it's my number one bug across ALL applications, because it drives me mad for hours every single day). Sadly, I lack the knowledge in this programming language. Is there anything that can be done to prod somebody into writing up a patch for this? I'm prepared to ship beer - Even internationally.
*cough* http://git.gnome.org/cgit/evince/tree/libview/ev-view.c#n800
Created attachment 144192 [details] [review] Scroll screen completely when using the keyboard
See some of the comments on bug #165120 (#16 and #17), I was working on a solution based on leaving one line overlap when there's text or just move one page otherwise. I'm still doing some tests, so I'll let you know as soon as I have something working.
You read my mind Carlos. Looking forward to seeing this fixed! Thanks everybody.
Created attachment 144378 [details] [review] Scroll an screen leaving one line context I finally managed to get some time to finish the patch. Please, try it out and let me know whether it behaves as you expected or not.
Nobody tried it? I've just committed it to git master so that it's easier to test
Sorry, I'd love to, but it's a bit over my head. Is there an easy way to compile and install evince such that it won't override my default installation, and so that I can easily remove it if I want to? Whenever I try something outside of the main distro's sources, I end up with two versions, one of which I can't remove.
OK, I spent about three hours trying to get a functioning copy of evince from source. jhbuild is a pain, and installing without it failed repeatedly. Looks like I'm no help. Sorry.
Finally, I got this to work, and used it for a bit today. I'm afraid to say this, but it's inconsistent. It works most of the time, but sometimes, the scroll is only about half, or maybe 60% of the page. I haven't been able to track down what's causing it to work sometimes, but not all the time, but I'll attach the file I'm using, and you can judge for yourselves. Even if it's buggy though, it is an improvement.
Created attachment 145323 [details] Doc exhibiting the behavior. Try hitting space bar three times in this document. I allege that the third time won't work properly.
hmm, it seems to be related to multicolumn issues. Thanks for testing Mike.
Hey, I have some problems with the current state of git master. First, even without multicolum, the context in the scroll is not always well calculated (AFAIK). Carlos, could you please explain with more details what's the intended behavior? The scrolling experience is also worse if you are quickly scrolling, i.e., just hold down the down or up key to scroll. In 2.28.2, you get deterministic behavior and you can ``predict'' (by looking at the current page box in the toolbar) when to stop scrolling. It seems that with this patch, it is much more complicated to do that (the current page number in the box does not seem to change in a deterministic way) Hope this last paragraph makes some sens to you ;)
Is there something we need to do to get this patch rolled into the next version of Evince? I have been using this patched version for a while on my laptop, but it still hasn't been rolled out properly. Are we in the stage where we wait for the distros to pick up the fix, or does something need to be actively done?
...so what about using my trivial patch in comment#21 for the moment? Perhaps it needs a .90 factor to avoid partly shown lines to show partly again after scrolling.
The patch from Carlos has been working for me for months. Can we just roll that in to the next version as soon as possible? Is there a review process we need to do or something?
Mike, the patch was already pushed, see: http://git.gnome.org/browse/evince/commit/?id=77d7df795c3d4f772a1b2f584e7b1b78747bf416 and it was released in Evince 2.29.1
Excellent. And I see that Ubuntu has a downstream version coming out in Lucid. I'm excited that this will finally be fixed.
I'm using Evince 2.30.3 on Fedora 13 and I'm still seeing this bug. When only the top-half of the last line is showing at the bottom of the window and I press the space bar, the bottom-half of that (previously) last line is then displayed at the top of the window. So I never get a chance to fully-read that line. Also, I have another request. I would file this as a separate report but I saw that bug 553275 was already closed as a duplicate of this one. Can you leave two lines of context when scrolling instead of just one? That's Emacs's default, and the DjVuLibre viewer's default, and it works nicely. Alternatively could the number of context lines be configurable over a reasonable range, say 0 through 4?
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/evince/issues/4.