GNOME Bugzilla – Bug 170874
Arrow keys should switch pages in fullscreen mode
Last modified: 2006-03-17 19:02:54 UTC
Fullscreen mode is often used for doing (e.g. LaTeX) presentations. In order to be consistent with expectations, it would make sense to have the down arrow or right arrow go to the next slide (page) and the up arrow or left arrow go to the previous slide. You might also consider having the enter key go to the next page. And of course, the spacebar. Little details like this make all the difference. Thanks for your work.
spacebar/backspace should work to move pages once bug 165120 is commited. I'm not comfortable with adding additional keys to move to the next page, especially the arrow keys which can move the document around in the viewport. Page Down and Page Up are also available for changing pages. I believe there's a bug report about using mouse buttons (left/right) to change pages too, not that we're going to do that. I'm going to close this WONTFIX, feel free to reopen it if you have other arguments or ideas.
May I suggest reconsidering at least the right and left arrow keys as valid page movement commands in fullscreen mode. In this mode, moving the document around in the viewport does not make much sense, and the sideways arrow keys are the standard for moving around in presentations (kpdf, acroread, impress, powerpoint). Consider this: when zoomed in, the arrow keys move the viewport around, as you point out. When in fullscreen they do nothing. Human expectations, I think, are that they will change to the prevous/next page.
Hi, sorry I had something written for this but lost it last week. Basically I've come around to agreeing that if we consider that our fullscreen mode is really just a "make the page take the screen width" then this makes sense that left/right could move to the previous/next pages. There shouldn't be any movement possible in the viewport anyway. Any patches for this?
Should we reevaluate this now that we have a presentation mode?
Hmmm wouldnt this (#3 comment) feel strange in continous mode? I tend to think we should WONTFIX this unless someone come with a good patch. It adds some mess to the code and I'm not sure it's worth it. Bryan?
Now that we have presentation mode, this bug should be renamed or something and these changes implemented in presentation mode only. Arrows and mouse clicks should switch pages in presentation mode. Fullscreen mode is good as it currently stands. Thanks for the quick work!
Created attachment 47664 [details] [review] Proposed patch I also think it's a useful behaviour in presentation mode. Here is a patch :-)
Can we implement these as GtkUIManager accellerators?
Bug 305422 has new patch
Created attachment 48217 [details] [review] Patch
Fixed in CVS, thanks
I was just testing this implementation and it's great. One this is missing, though: when people do presentations, they often use the left mouse button to move forward a slide and right to move backward. I think these two bindings should be included in presentation mode. One reason it might be necessary: remote controls for doing presentations often use left and right mouse button events to control the presentation. And anyway those buttons are not mapped to anything else in presentation mode.
Created attachment 48594 [details] [review] New patch Here is a new patch based in my first patch.
Hi Carlos. You way of doing things is a bit different. We are trying to use OO programming style, so instead of connecting to our own singals we just overwrite method implementation. Look at the function ev_view_button_press_event. It's possible to do things there. But we have another proposal about mouse buttons in presentation mode - see bug 309364. Do you think it's sensible? Do you have examples of apps that behaves in fullscreen mode like you propose?
Created attachment 48599 [details] [review] Updated patch > You way of doing things is a bit different. We are trying to use OO programming > style, so instead of connecting to our own singals we just overwrite method > implementation. Look at the function ev_view_button_press_event. It's possible > to do things there. Totally agree. I also prefer OO programming. In this patch the things are done in the button_release event instead of button_press to avoid conflicts when clicking for selection > But we have another proposal about mouse buttons in presentation mode - see bug > 309364. Do you think it's sensible? Do you have examples of apps that behaves in > fullscreen mode like you propose? I think most of the presentation apps work in that way, for example OpenOffice
What about text selection?
There is no problem. if (view->selection_info.selections) { ev_view_update_primary_selection (view); } else if (view->document) { The code is in the else branch. It only runs when there aren't selections.
I mean, left button is already used to select text. Are you enabling this behavior only when the mouse is not over some text?
The actions are associated to button_release event, so if you are using the left button for selecting, when you finish the selection, the release_event will be triggered, but view->selection_info.selections will be true and the code for going to the next page won't be executed.
Bryan, what do you think about this behavior?
I tend to think that text selection is not useful for presentation mode. I suggest that mouse clicks be bound to forward/backward movement when in presentation mode and text selection otherwise.
Fixed up patch for current cvs adn checked in.
*** Bug 333851 has been marked as a duplicate of this bug. ***