Well, mousewheel is already linked to the window's scroll bar (and this is at a window-manager level).

If you didn't notice, third button (contextual menu) display a way to navigate with mouse within the document.

We believe that this is enough and I will close this bug. Feel free to reopen it if you believe that your feature is worthing it.

My apologies, I didn't think this feature request needed much explanation, because it seems so obvious to me, but of course not everybody uses Evince the same way as me. Let me explain why I think this feature is necessary.

I'm not sure about the focus of Evince project, but personally I mainly use this program for reading books and other documents saved in PDF, PostScript or similar format. Traditionally, those documents are formatted for convenient reading, with lines of text not exceeding the length of twenty words, depending on language, averaging at dozen words or so. This, coupled with the fact that typical screen is wider than its height, and the fact that the most popular paper formats, US Letter and A4, are narrower than their height, makes horizontal scrolling a very rare event. In fact, because I mostly read scripts that are read from left to right or from right to left, horizontal scrolling, if required, would be so inconvenient, that I would use "fit page width" option anyways.

The only case when I would need horizontal scrolling is with documents typeset with multiple columns of text -- but even then, I would scroll a lot at a time (by the width of the column), so the slow scrolling of the tilted mouse wheel wouldn't be convenient: I would use either the cursor keys, or the middle mouse button, especially when I would typically also scroll to the top of the page at the same time.

You point out that I already have ways of switching to the next page with mouse. I can use the context menu, and select "next page" option from it, or I can use the toolbar button, if enabled. Both ways are very inconvenient for such a common task as flipping a page: with the context menu, I have to invoke a mode switch, and then I have to position the mouse cursor rather precisely, guided by visual feedback -- in other words, I have to focus my attention on the task while I'm absorbed in reading. Toolbar is a little more convenient, but takes the precious vertical screen space, plus, if you want to make it convenient only for people who have the toolbar enabled, why provide the option to hide the toolbar at all?

On the other hand, there is already a much more convenient way to scroll horizontally available for users equipped with mouse with wheel: the middle-button drag.

There is one possible solution that allows to use the mousewheel tilt both for horizontal scrolling and page switching. It's similar to what it often done with mousewheel in many applications: as long as it's possible to scroll the page, scroll it, but as soon as an edge of the page is reached, switch to the next page. This is of course ore complicated than simply reacting to mouse button events.

Your proposition to reopen the bug if I believe it's important is very generous, except that I don't have the rights to do it in your bugtracking system, so I just have to settle for this lengthy comment, hoping it will make you reconsider this feature, even though it might be less useful for the huge number of people around the word who are used to reading top to bottom rather than left to right (or right to left).

Hi Radomir,

I think that the behaviour described in 562257 solve this issue just as you wish. Is it correct ? Moreover, there is a freshly applied patch in 562257.

If yes, then I'll mark this issue as a duplicate of 562257.

Excellent! From the description it looks like it works at least in most of my use cases. I will need to test it in practice to make sure, it will take me some time. Thank you for remembering about this.

*** This bug has been marked as a duplicate of bug 562257 ***