GNOME Bugzilla – Bug 562257
scroll and change page in non-continuous mode
Last modified: 2018-05-22 13:27:05 UTC
In this non-continuous mode, scrolling to the bottom of a page with the mousewheel will not trigger a page change. In contrast, scrolling to the bottom of a page with the PgDn button will trigger a page change. It would be nice if the mousewheel would act in a similar fashion, so that the mousewheel could be used to change pages in both the continuous and non-continuous modes. - Mike
Also: is there a reason that the continuous mode is not on by default? - Mike
Created attachment 123567 [details] [review] Allow key and wheel scrolling to change pages Here is a patch that implements page changes when scrolling (using buttons or the mousewheels) to the edge of a page. It seems to work very nicely in the forward/right modes. It works OK in the backward/left modes, except that the page position is reset to top-left, which is visually jarring. Fixing that might be beyond me... - Mike
*** Bug 540745 has been marked as a duplicate of this bug. ***
*** Bug 549632 has been marked as a duplicate of this bug. ***
The reset-to-to-left issue mentioned in the last comment is bug 557249. - Mike
Thanks for the patch, this behaviour was decided long time ago actually: http://bugzilla.gnome.org/show_bug.cgi?id=168449
Can we re-visit that decision? People have asked for this feature in bug 168449, bug 437008, bug 540745, bug 557249, and bug 562257. As far as I can tell, the only objection in bug 168449 was that people would get confused by the flipping (due to a lack of resistance). I don't think that is true. People handle it OK in presentation mode. They handle it in continuous mode. They handle it in Adobe Acrobat (not that we should copy Acrobat blindly - I just mean that millions are people are perfectly comfortable with this behaviour). The whole point of the mousewheel is that it allows easy and rapid scrolling, so people will not be surprised when rapid scrolling causes a page flip. I'm always surprised that it doesn't! The default behaviour (non-continuous + no page flips) is awkward. You can't rapidly scan a document with the mousewheel. This is a productivity / usability killer. It doesn't "just work". The continuous mode is nice, but most users are unaware of this option. - Mike
Sorry, the default mode is continuous with scrolling. And there is already a plan to drop single page mode.
Oops, my mistake. Continuous is the default mode, which is good! - Mike
I think Michael Chudobiak is absolutely right. When scrolling wheel does not scroll, it is a bug. No matter whether in continuous/non-continuous or fullscreen/non-fullscreen mode. There is no excuse for this and it should be fixed ASAP because users expect it to work.
Created attachment 139950 [details] [review] Let scroll wheel change page when in non-continuous best-fit mode I think the world has changed a little bit since this bug was last discussed and the code is significantly different. Today, the scroll wheel will change pages in presentation mode. It seems reasonable to me to also scroll when in non-continuous best-fit mode and my proposed patch implements this functionality.
Applied to git master, thanks Philip.
Hi all, What is exactly the status of this issue now ? It seems to be linked to quite a lot of bugs: 152555, 168449, 437008, 458105, 540745, 549632, 557249, 562257. If fixed, it will indeed removed quite a lot of issues from the database.
*** Bug 458105 has been marked as a duplicate of this bug. ***
Well, you still can't flip pages with the scroll wheel in non-continuous mode, unless you happen to be in "best fit" mode. So the status of the bug is basically unchanged - either NEW, or NOTABUG if the developers don't want that functionality. - Mike
I'm jumping late to the party, but a couple of thoughts. I'm using Evince 3.4.0 on Ubuntu Precise. I ended up on this bug report because I always found very awkward that in best-fit mode (& continuous mode, as it turns out) an up/down arrow button would flip the page, while the scrolling wheel would not flip the page. This is inconsistent with the presentation mode, in which both up/down and scrolling wheel both flip the page. In this sense, I'd say this feature is a bug. I'm happy though that in best-fit (& non-continuous mode) the behaviour is the same as in presentation. But I failed to discover this without the help of this bug report.
*** Bug 437008 has been marked as a duplicate of this bug. ***
Created attachment 276785 [details] [review] Scroll small pages in non-continuous mode Maybe we could allow user to scroll the pages in non-continuous mode when the current page is smaller or equally big as it would be in "Page Fit" mode at least. Attached patch does this for me.
The patch still applies and I think that it would improve user's experience :).
*** Bug 655469 has been marked as a duplicate of this bug. ***
I've just noticed that this patch is not exactly the same as the one in bug #655469, but I think it could be updated to handle that case at well.
Created attachment 323525 [details] [review] Scroll small pages in non-continuous mode (In reply to Carlos Garcia Campos from comment #21) > I've just noticed that this patch is not exactly the same as the one in bug > #655469, but I think it could be updated to handle that case at well. Hi, this patch fixes both cases. It checks whether currently shown page fits actual view and allow user to scroll to previous/next page in that case (also in dual page mode). It does this also when the page fits only in one axis and the scroll happens in the same axis. It does this also for the key events in ev_view_scroll(). The only part I'm not sure about is the GDK_SCROLL_SMOOTH part. It works well for me but I'm not sure whether I was able to test all cases. I've tested it with my mouse and touchpad.
The patches from Philip and Marek have focused on allowing page changes when the entire page fits on the screen, but I think the original reporter was asking about the page changing no matter the page size. I'm not advocating for either position, but I wondered what the developers say the correct behavior is. In non-continuous mode, should the arrow keys and scroll wheel only change the page when the entire page fits in the view? Or should the arrow keys and scroll wheel change the page no matter the page size?
*** Bug 763002 has been marked as a duplicate of this bug. ***
I'd also appreciate a developer's opinion on this. However, if it turns out to be difficult to come to a decision in this regard, we might just as well implement it in to steps; as there seems to be consensus on the issue in the case of the page fitting the screen, we could go ahead with that first. Whenever a decision is made on the case of the page size being irrelevant, we could add that later on.
I think that https://bugzilla.gnome.org/show_bug.cgi?id=168449#c4 still holds here.
Review of attachment 323525 [details] [review]: Ok, I think we can try this. Sorry for the delay reviewing this. I only have a couple of suggestions. ::: libview/ev-view.c @@ +4180,3 @@ + if (state == 0 && + !view->continuous && + (fit_width || fit_height)) { Leave this if as a single line. @@ +4187,3 @@ + if (fit_height) { + ev_view_next_page (view); + handled = TRUE; I think we can just return TRUE here. @@ +4193,3 @@ + if (fit_width) { + ev_view_next_page (view); + handled = TRUE; Ditto. @@ +4199,3 @@ + if (fit_height) { + ev_view_previous_page (view); + handled = TRUE; Ditto. @@ +4205,3 @@ + if (fit_width) { + ev_view_previous_page (view); + handled = TRUE; Ditto. @@ +4226,1 @@ + handled = TRUE; Ditto. @@ +4230,3 @@ } + return handled; And here you just return FALSE and you don't need the handled variable- @@ +8578,3 @@ +static double +ev_view_get_relative_page_width (EvView *view) Since we are not actually using the return value, except for checking whether it's <= 1, I think it would be easier to make this a boolean function renamed as something like ev_view_page_fits or something similar. We could even make a single function that receives a GtkOrientation. @@ +8585,3 @@ + + gtk_widget_get_allocation (GTK_WIDGET (view), &allocation); + ev_view_size_request (GTK_WIDGET (view), &requisition); I guess we can avoid all this in case sizing mode is EV_SIZING_FIT_PAGE and in the horizontal case also if it's EV_SIZING_FIT_WIDTH or EV_SIZING_AUTOMATIC.
Comment on attachment 323525 [details] [review] Scroll small pages in non-continuous mode Thank you for the review. I've incorporated all your comments to the patch and pushed it to master.
-- 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/74.