GNOME Bugzilla – Bug 689041
Offer to change page when scrolling at edges
Last modified: 2021-07-05 11:32:03 UTC
Currently we use what evince calls a "continuous" document view. Which means that the scrollbar scrolls through the entire document instead of just the current page. I don't think this works very well. It makes the scrollbar very hard to use because documents are often very long. It optimizes for large movements through the document when the most common case is small movements. It implies that the content isn't paged (like the web) but the fact is that the content is paged. It forces me to continuously reposition and reanchor myself as I'm reading. It is much preferable for a "reader" app to page instead of scroll. And leave scrolling for cases where the zoom requires it to view a single page. That said, it would be nice if the scrolling and paging were connected so that when I scroll to the bottom of a page the natural thing to do is move to the next page. I think we should offer a "Next" and "Previous" option when scrolling to the bottom or top of the page, respectively. It could operate either as a normal button or as an elastic action similar to the pull down to reload pattern on mobile devices.
Now that master uses a continuous model, we need to address the prev/next buttons part of this bug report for a complete fix.
Created attachment 232085 [details] wires of a hybrid concept Continuous mode allows me to see the bottom of a page and the top of the next one, which is very useful when reading text which continues in the next page. If I need to reread a sentence or paragraph which starts in the previous page, I can reread it easy. Doing the same with non-continuous paging requires me to relocate myself, which is much less comfortable. Another common use case is when there is an illustration on the bottom of a page whose descriptive text is in the next page, or vice-versa. Continuous paging allows me to see both at the same time. Attached is a tentative concept for third alternative which tries to conciliate continuous paging with non-continuous scrollbar while keeping it simple.
*** Bug 702863 has been marked as a duplicate of this bug. ***
*** Bug 710043 has been marked as a duplicate of this bug. ***
Not sure how relevant this bug is currently, since we now show the next/previous buttons whenever the mouse pointer moves over the preview area.
(In reply to comment #5) > Not sure how relevant this bug is currently, since we now show the > next/previous buttons whenever the mouse pointer moves over the preview area. It still is ... it is way more convenient to scroll then clicking a button. Just try to read a longer document with evince (or even a web browser) and one with documents. The documents way is very annoying compared to the others. Its not about knowing how to switch pages but that is is inconvenient to do so compared to existing solutions. So no showing buttons does not change anything. (See what I wrote in bug 710043 )
FWIW, I think the horizontal scrolling feels easier than evince's vertical scrolling. It even displays previews to show what page you'll end up on.
(In reply to comment #7) > FWIW, I think the horizontal scrolling feels easier than evince's vertical > scrolling. It even displays previews to show what page you'll end up on. Well, that depends. My documents don't fit in the screen so I have to use the up/down arrows to scroll anyway. With evince, to go to the next page, I just keep tapping the down arrow. With docs, the page abruptly stops and then I remember that I now need to switch to the left right arrows to move to the next previous page. I'm not saying that it's too much work, I'm just saying it's smoother to keep hitting the up/down arrows and moving on to the next/previous page. They don't need to be mutually exclusive, both ways can be activated? I didn't notice the preview part. I'll have to go check it out. PS: I'd really love vim type navigation too, so that I don't need to move my hands off the home row at all, but that's just me - it would make gnome even more keyboard friendly ;)
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version, then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new ticket at https://gitlab.gnome.org/GNOME/gnome-documents/-/issues/ Thank you for your understanding and your help.