Bug 219121

No sorry

Created attachment 58744 [details]
replaces mouse middle button zoom with scroll

My ugly patch :)

Please add this patch, or at least an options to turn mouse wheel zooming off. I really would like to use okular, but these zooming is very annoying. I always ragequit when i accidently zoom my document to 10 % :P

Agree with this.  We should have a option about this.  People migrated from  adobe reader or other will be familiar with scroll by mid button.  I think there will be no lost for adding such a option.  Please take it into account.

Thanks.

Pretty please?

Created attachment 83675 [details]
update to old patch for newer okulars

This patch is no better (or worse) than the original but does apply to recent okular versions (at least, it does against 4.11.3)

Perhaps Albert, who WONTFIX'ed this, is not aware of why some people might want this so badly.  Many folks using an 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 -- but, infuriatingly, ignored, with no frobs to fix the bug (correct word usage imo), by okular and a few other critically important kdebase components.

Specifically, the convention I'm talking about is: that by continuously depressing the middle mouse button and moving the mouse, one can simulate mouse-wheel movements without requiring a mouse wheel.

This is also a boon for those (most?) with single-axis mouse wheels, and who want to recover the horizontal mouse wheel feature somehow.  When using an actual "mouse" (by which I mean, the things that actually look like a mouse, with balls or lasers in them), this might seem pretty awkward and 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).

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.

Anyhow, many of us have come to rely on this convention being implemented in most other tools we use.  Personally I probably do this hundreds of times a day on average and have done so for years.  After a while, it becomes second nature.

So in okular, the experience we 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?  fuck this, no more okular for me.

*** Bug 327892 has been marked as a duplicate of this bug. ***

Perhaps you, that are not the maintainer of the app like I am and have not put put thousands of free man hours of work so others can use it, are not aware that we've had this  behaviour for ages.

And I hope that's the case, because the other possibility is that you know we've had this behaviour for ages, but you don't care since your habits are much more important that the rest of the world and we have to change the code so you are happy even if the others suffer.

Now if someone can come up with a patch that doesn't break the usage of the rest of Okular users please post it to reviewboard.kde.org

https://git.reviewboard.kde.org/r/115335/

In my experience, this behavior is common in windows applications but in fact very rare on linux. Chromium implements this on windows, but the developers refuse to do so on linux because "it's not a linux behavior" and because middle click already has a set of confusing precedents (https://code.google.com/p/chromium/issues/detail?id=17689).

The X11 evdev EmulateWheel setting should provide a similar functionality without having to implement it in every application. I just tested it and it correctly overrides the zoom in okular. Personally, I don't think there's any need to add this to okular.

I think it is better to implement this in Okular because evdev emulate this by sending wheel event, which is not as smooth as that implemented in patch.

After 5 years I'm still carrying patch to make okular usable. Hopefully, it's not a big burden with gentoo :)

@Albert, do you remember what was the problem with Yichao's patch? I'd like to help finalizing it.

Created attachment 96346 [details]
attachment-9158-0.html

>
> https://bugs.kde.org/show_bug.cgi?id=219121
>
> Dmitry Osipenko <digetx@gmail.com> changed:
>
>            What    |Removed                     |Added
>
> ----------------------------------------------------------------------------
>                  CC|                            |digetx@gmail.com
>
> --- Comment #13 from Dmitry Osipenko <digetx@gmail.com> ---
> After 5 years I'm still carrying patch to make okular usable. Hopefully,
> it's
> not a big burden with gentoo :)
>
> @Albert, do you remember what was the problem with Yichao's patch? I'd
> like to
> help finalizing it.
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.
> You voted for the bug.
>

Hi Yichao,

Sorry, I thought you've abandoned your effort.  Are you going to re-spin the patch?

Hi Dmitry,

I tried to reply to this bug this afternoon by email from my smartphone but it seems I did not do it correctly.  Sorry for the confusion.

The problem about my patch was that the maintainer thought that we should use the middle mouse to pan the page (like we do in evince and some 3D modelling software) instead of scrolling the page (like we do in firefox/adobe reader).  I proposed that I could implement all of the three modes (zoom, pan, scroll) and let the user choose them.  It seemed that Albert agreed on this.  However because that patch works well on my gentoo box and I really do not need to pan feature, I put this task behind my schedule.  I realized that this patch does not work on KF5 recently.  But I no longer use KDE frequently (maybe I will be back in the future) now so I will not work on this in short term. Feel free to implement it if you want to see this feature in the upstream! Communication with Albert before working is a good idea to make sure that your patch will be merged finally.

Maybe it's to do with the particulars of my box but the patch from this bug never quite worked correctly on my Gentoo box, Yichao (although I used it for many months and eventually decided to just stop using Okular.

It /almost/ worked.  But certain actions --  I can't remember /exactly/ what, but maybe it was something to do with scrolling past a page boundary? -- would cause the display to go blank.  Under the hood everything was fine; if you used the "normal" scrolling techniques then the document would appear again, but it was as though okular did not realize that certain parts of the page needed to be repainted.

Sorry I can't remember more precisely what the exact way to trigger these problems were.  But I just wanted to mention it for the record, so that if someone is looking into these patches with an eye toward refactoring or merging them in some way, they should be mindful that there may  be some bug in there.

Dmitry https://git.reviewboard.kde.org/r/115335/

(In reply to Yichao Zhou from comment #16)
> Hi Dmitry,
> 
> I tried to reply to this bug this afternoon by email from my smartphone but
> it seems I did not do it correctly.  Sorry for the confusion.
> 
> The problem about my patch was that the maintainer thought that we should
> use the middle mouse to pan the page (like we do in evince and some 3D
> modelling software) instead of scrolling the page (like we do in
> firefox/adobe reader).  I proposed that I could implement all of the three
> modes (zoom, pan, scroll) and let the user choose them.  It seemed that
> Albert agreed on this.  However because that patch works well on my gentoo
> box and I really do not need to pan feature, I put this task behind my
> schedule.  I realized that this patch does not work on KF5 recently.  But I
> no longer use KDE frequently (maybe I will be back in the future) now so I
> will not work on this in short term. Feel free to implement it if you want
> to see this feature in the upstream! Communication with Albert before
> working is a good idea to make sure that your patch will be merged finally.

Thanks for quick response! Coincidentally, I'm already using panning with middle button for a quite long time with KF5. However, it's just dumb panning (which I'm finding more usable) without evince-like scrolling momentum. So, I'm picking your patch, adapting it for KF5 and adding pan feature.

(In reply to Gregory M. Turner from comment #17)
> Maybe it's to do with the particulars of my box but the patch from this bug
> never quite worked correctly on my Gentoo box, Yichao (although I used it
> for many months and eventually decided to just stop using Okular.
> 
> It /almost/ worked.  But certain actions --  I can't remember /exactly/
> what, but maybe it was something to do with scrolling past a page boundary?
> -- would cause the display to go blank.  Under the hood everything was fine;
> if you used the "normal" scrolling techniques then the document would appear
> again, but it was as though okular did not realize that certain parts of the
> page needed to be repainted.
> 
> Sorry I can't remember more precisely what the exact way to trigger these
> problems were.  But I just wanted to mention it for the record, so that if
> someone is looking into these patches with an eye toward refactoring or
> merging them in some way, they should be mindful that there may  be some bug
> in there.

Thanks, that might be helpful.

(In reply to Albert Astals Cid from comment #18)
> Dmitry https://git.reviewboard.kde.org/r/115335/

In the last review comment you mentioned conversation on Feb 7, that I haven't found. I guess it was discussion on adding panning feature, right? Or was it something else, maybe other issue?

> In the last review comment you mentioned conversation on Feb 7, that I haven't found. I guess it 
> was discussion on adding panning feature, right? Or was it something else, maybe other issue?

You need to learn to click more things before admiting defeat and asking for help. Click on the "Posted 1 year, 11 months ago (gen. 27, 2014, 9:42 p.m.)" box and then you'll see it expand and it will contain one text that says "1 year, 10 months ago (feb. 7, 2014, 12:20 a.m.)"

(In reply to Albert Astals Cid from comment #20)
> 
> You need to learn to click more things before admiting defeat and asking for
> help. Click on the "Posted 1 year, 11 months ago (gen. 27, 2014, 9:42 p.m.)"
> box and then you'll see it expand and it will contain one text that says "1
> year, 10 months ago (feb. 7, 2014, 12:20 a.m.)"

Okay, thanks for pointing to it.

I always used wheel emulation so everything worked perfectly, only now after using okular since its first release found out this odd behavior, allowing user to select behavior is a good compromise between various standards, not sure why it was rejected.

(In reply to Alon Bar-Lev from comment #22)
> I always used wheel emulation so everything worked perfectly, only now after
> using okular since its first release found out this odd behavior, allowing
> user to select behavior is a good compromise between various standards, not
> sure why it was rejected.

It was rejected because maintainer didn't want to bother implementing it, so it doesn't mean that it won't ever happen. I proposed patch for it, waiting for review comment.