Feature request : change page when scrolling about npdf

[legimet]

@critor intentionally made it that way, because it takes so long to load the next page, and it would be annoying if a user accidentally went to the next page. If you can come up with a better idea feel free.

[davy39]

Maybe it is related to the kind of PDF (heavy images, etc) because my pages (mostly text and math) are opening almost instantaneously. So I will be happy to have a complete scrolling mode:)
@critor : do you have any clue about why next(); is never called in my patch ? davy39@c6b3bce
Would you have any time to help implement this ?

[critor]

What you apparently didn't understand, is that you're not going to get a "complete scrolling mode", but a terrible user experience.
Scrolling beyond the bottom of the page didn't scroll to the next page in a natural way.
It completely cleared the screen, putting you on the top of the next page.
So it's not natural to have some presses on the down-arrow key scrolling by a handful of pixels, and some other presses scrolling by a full screen height (240px).

Moreover, "almost instantaneously" is not "instantenously".
By letting its finger on the down-arrow key one fraction of a second too late, the user who just wanted to check the bottom of a page is going to be shown the next page, whose display is not instantaneous (almost a second).
So the user will then have to go back to the previous page (again, almost one more second), and then carefully scroll back to the bottom of the page.

[davy39]

I understand your point, and probably the user experience may depends both on hardware and PDF.
I'm actually using nspire cx cas overclocked with small text PDFs and I would say that pages are displaying with about 200ms which is really fine.

So in my case, I feel it more natural to explore a PDF by pressing one unique key than juggling between two ('down arrow' + '+'), even if it means some bigger steps while changing pages. In fact, that the way mupdf is acting when build for x11 (see here for code related to it).

You're absolutely right that it may be a really bad thing when it take so long to display, so I will not insist for it to be the default behaviour of nPDF. However, do you have an idea on why next() is never called when applying this simple patch davy39@c6b3bce

Finally, the best would of course be to achieve a "real" continuous scrolling mode (like in llpp ie. display both bottom of previous page and head of next one.). But I guess this implies a huge code modification, and I'm personally not ready for that yet...

[critor]

Thank you for your fast and comprehensive reply.

Yes, the right way for a continuous scrolling with nPDF would be to show 2 pages at the same time : end of the previous page + start of the next page.

Your next() is never called, because yPos is automatically fixed each times it gets modified and thus is never out of bounds.

By the way Legimet, isn't there an error in Viewer.cpp on line 244 ?
Shouldn't
yPos = (xPos > (bounds.y1 - bounds.y0) - height)?(bounds.y1 - bounds.y0) - width:yPos;
be
yPos = (yPos > (bounds.y1 - bounds.y0) - height)?(bounds.y1 - bounds.y0) - width:yPos;
?

[davy39]

Thank you !

So stupid am I : I looked every where else but I didn't see that xPos in place of yPos... That's why nothing was working ;)
Now I'm happy, I got the scrolling mode I expected with this patch davy39@c7de00d

Maybe if you think it could be useful for others, we could integrate that as an option in a configuration file.

Anyway, many thanks to @critor and @legimet for your awesome work !

[legimet]

I fixed the error.

@davy39, a config option would be good. We could possibly allow 3 modes of scrolling: the current behavior, the behavior in your modified version, and a proper continuous scrolling mode.