Bug 327892

+++ This bug was initially created as a clone of Bug #219121 +++

I am sure, nobody will ever see my comments in #219121, as there is no way to reopen a bug (so far, I'm 0/2 with that -- starting to wonder if maybe that's the biggest KDE bug of them all :) ).

So, I'm just cloning the bug.  Here are my comments from it (edited a bit since I suck at writing):

Perhaps Albert, who WONTFIX'ed this, is not aware of why some people might want this so badly.  Many folks, especially those using a compact IBM or Lenovo laptop with a TouchStyk, but without a TouchPad, are accustomed to using their middle mouse button as a proxy for the mouse wheel.

There is a loose convention, not universally respected, but respected, at least, by all Microsoft Office suite tools, WebKit-based programs, Adobe products, older XUL-based products (unfortunately broken, now, without a plugin), KHTML browsers, and many more, that by continuously depressing the middle mouse button and moving the mouse, one can simulate mouse-wheel movements without requiring a mouse wheel.

Sadly, but probably for good technical/configurability reasons, this convention is not effected at the driver level, but left to applications to implement, on a case-by-case basis.  Most do, but a few stragglers don't.  Sometimes, this is not a big deal, as not every application requires a bunch of scrolling.  Clearly, okular does not fit into that category.  Scrolling is, obviously, a very central feature of any e-reader-type application.

When using an actual "mouse" (by which I mean, the things that actually look like a mouse, with balls or lasers in them), this convention might seem pretty awkward -- even stupid.

But when using a Lenovo-style keyboard with a touchstyk, it feels very natural.  So long as applications follow the convention, we don't miss our mouse wheels (in fact, when we see "mouse" people struggling with their "standard" mouse-wheels, with their awkward "number of lines to scroll per mouse-wheel-movement-quantum" setting, we might even feel a bit sorry for them).  This allows us to keep our hands in the "home" position on our keyboards for everything we need to do.  Basically, once you master the touchstyk (takes some doing), it's completely awesome.

Take away that wheel capability, and it's... not great -- remember why the wheel was created in the first place?  Those scroll bars on the right-hand side of oversize virtual windows are not what I would describe as an optimal user-interface for scrolling... and although perhaps we should think of keystroke ways to scroll... meh, personally, I just don't.

Many of us have instead come to rely on this convention being implemented in most other tools we use, and learned to do without tools that can't or won't accommodate it.  Personally, I probably rely on this convention hundreds of times a day, on average, and have been doing so for years.  It's absolutely second nature, and when I stumble across a need to use those few tools that don't support it, I /always/ forget, often pasting erroneously into X-windows apps.

So in okular, the experience I have goes like this:

ah, what a nice, attractive, uncluttered tool.  time to read.
reading...
reading...
must scroll.  oops! I just zoomed waaay out.  OK, how do I reset the zoom to some reasonable level again?  ah yes... ok so how do I scroll?  ugh, scroll bars? arrow keys?  oh well, one does what one has to.... ok, back to reading.
reading...
reading...
must scroll.  oops!! sigh.... ok, reset zoom, awkwardly scroll in some unfamiliar way... sheesh, fixed.   back to reading.
reading...
reading...
must scroll.  FUCK!!!!!   Is there some way to make this work right?  No?  you kidding me?  screw this, no more okular for me, "wine acroread.exe $foo"