GNOME Bugzilla – Bug 727529
Rotation via shortcut may not work if zoomed in.
Last modified: 2018-03-02 00:43:34 UTC
Evince allows to rotate a pdf by using ctrl+{left,right} keys instead of using the menu to do so. However, if for any reason the evince window has a horizontal scroll bar, say if I zoom in or the window gets smaller, rotation cannot be done using the keyboard shortcuts any more. Instead the arrow keys only move the content around. The expected behavior would be that the horizontal scroll-bar is only used when I use the arrow keys alone, but not when I use ctrl+{left,right}. This way rotation could still work while the arrow keys without ctrl work for the scroll-bars just as everywhere else.
I can confirm in 3.12, and I think it is a regression (I don't recall meeting this behaviour in the past). In fact, as far as I understand the code (which is not much!), it was never the intention of programmers to have ctrl+{left,right,up,down} keys cause scrolling. Indeed, "scroll" and "move" keybindings are set with no modifier in libview/ev-view.c: add_scroll_binding_keypad (binding_set, GDK_KEY_Left, 0, GTK_SCROLL_STEP_BACKWARD, GTK_ORIENTATION_HORIZONTAL); Wild guess: maybe somewhere that modifier is checked with an "&" instead than an "=="?
I confirm for Evince 3.10.3 included with Ubuntu 14.04. Severity is set to trivial, perhaps rightly so, but these are the little details that annoy and disrupt work flow.
I can confirm this for Evince 3.10.3 included with Ubuntu 14.04. It's highly irritating.
As written in comment 1 this happens in 3.12, so the older 3.10 is pretty uninteresting at this point :)
That's still an issue in the current version, reported as well on https://bugs.launchpad.net/evince/+bug/1423077
I just updated to 3.14.2 and Ctrl+Left/Right stopped rotating the document even when no horizontal bar is present! In that case it just doesn't have any effect.
Ran into this bug in 3.16.1. The rotate command in the menu work, but the shortcuts either scroll or do nothing. Very confusing. Oddly enough, contrary to some reports here, I remember using this feature in fairly recent versions (certainly after 3.10.3). Is some environmental factor causing mischief here?
Jeroen, you remember using Ctrl+Right after 3.10.3 _while sufficiently zoomed out_? It never stopped working as long as the document fits horizontally in the current view.
Yes, I suspect that may have been without a horizontal scrollbar. Although in 3.16.1, rotating does not work at all with the keyboard short-cuts, regardless of the PDF viewed and whether or not horizontal scrolling is possible.
SUGGESTED TEMPORARY FIX: For now, and until this issue is better fixed, and as a temporary stop gap, please add this text to the `Keyboard Shortcuts` screen, (page 2) under 'Rotating and Zooming': "To rotate you may have to first zoom out." Otherwise it is very upsetting when you rotate, but then are stuck and can't rotate back.
Hey, I just looked at this (sorry I didn't before) but actually there are two evince features that are competing for the ctrl+left and ctrl+right shorcuts... Caret navigation and Rotate page. Even if caret navigation is not so well used, the standard shorcut all across gnome apps to jump to the next or previous word is Ctrl+left and ctrl + right, so I think we should plainly change the shorcuts for Rotate.
Thanks for looking into this José. Not sure about which is the best shortcut for rotating (I thought Ctrl+Left/Right, but I had no idea about caret navigation), but am I right that Ctrl+Left should, in any case, _never_ scroll, and that the fact it does is a bug?
Created attachment 369046 [details] [review] shell: Unbind Ctrl-Left and Ctrl-Right from the scrolledwindow The GtkScrolledWindow binds Ctrl-Left and Ctrl-Right. Since we are using these as shortcuts for Rotate left and right, and the evince window sends the keypress event to widgets before processing Application shortcuts, we need to unbind these to avoid conflict between the two. https://bugzilla.gnome.org/show_bug.cgi?id=783221
So, it turns out that I introduced this bug while ago when fixing #676040. The rationale is that we forward the keypress event to the focused widget BEFORE processing Application shortcuts, so that it can react to it (and hence if you have a focused entry Ctrl+left should jump to the previous word) The thing is that the GtkScrolledWindow actually binds Ctrl-Left and Ctrl-Right but these actions are only enabled when the horizontal scrollbar is shown. Unbinding these actions through CSS does the trick of Ctrl+left and Ctrl+right rotating if there is no entry focused. If the caret navigation is enabled, then Ctrl-left and ctrl-right will move between words, which I think for now is what we expect. Maybe it still makes sense to change the Bindings for the Rotate left and Right actions, but since we are in UI freeze, these can be in a new bug if someone think it is worthy (I am fine with the behavior after this patch).
*** Bug 783221 has been marked as a duplicate of this bug. ***
Comment on attachment 369046 [details] [review] shell: Unbind Ctrl-Left and Ctrl-Right from the scrolledwindow Ok.
(In reply to José Aliste from comment #14) > So, it turns out that I introduced this bug while ago when fixing #676040. > The rationale is that we forward the keypress event to the focused widget > BEFORE processing Application shortcuts, so that it can react to it (and > hence if you have a focused entry Ctrl+left should jump to the previous > word) > > The thing is that the GtkScrolledWindow actually binds Ctrl-Left and > Ctrl-Right but these actions are only enabled when the horizontal scrollbar > is shown. Unbinding these actions through CSS does the trick of Ctrl+left > and Ctrl+right rotating if there is no entry focused. If the caret > navigation is enabled, then Ctrl-left and ctrl-right will move between > words, which I think for now is what we expect. > > Maybe it still makes sense to change the Bindings for the Rotate left and > Right actions, but since we are in UI freeze, these can be in a new bug if > someone think it is worthy (I am fine with the behavior after this patch). I think you should add this text to the commit message.
Which text german? the second paragraph is already there and explains the rationale, or what part do you think is missing?
Add the following one (or rephrased version): "it turns out that I introduced this bug while ago when fixing #676040. The rationale is that we forward the keypress event to the focused widget BEFORE processing Application shortcuts, so that it can react to it (and hence if you have a focused entry Ctrl+left should jump to the previous word)" To acknowledge there was another bug and commit, and what was its purpose. In case someone were bitten by something related, to not undo one to redo the other one which has a secondary effect. Does this make sense?
(In reply to Germán Poo-Caamaño from comment #19) > Add the following one (or rephrased version): > > "it turns out that I introduced this bug while ago when fixing #676040. The > rationale is that we forward the keypress event to the focused widget BEFORE > processing Application shortcuts, so that it can react to it (and hence if > you have a focused entry Ctrl+left should jump to the previous word)" > > To acknowledge there was another bug and commit, and what was its purpose. > In case someone were bitten by something related, to not undo one to redo the > other one which has a secondary effect. > > Does this make sense? Sure, thanks
Review of attachment 369046 [details] [review]: thanks
This problem has been fixed in the unstable development version. The fix will be available in the next major software release. You may need to upgrade your Linux distribution to obtain that newer version.