GNOME Bugzilla – Bug 722157
scrollwheel no longer scrolls pages while in continuous mode
Last modified: 2014-01-20 23:18:36 UTC
I dont know what happened. I upgraded to sid in debian and now version 3.10.0 does not scroll through the pages while using wheelmouse. Help. this is very important feature used all the time. how to re enable this???? please Mitchell Laks
Works here, so this looks like a debian specific problem. Try filing it on bugs.debian.org.
Works for me with a pdf in continuous mode with 3.10.0 in Debian sid/experimental.
I don't understand why you both do not have the bug. When I turn my mousewheel on a page, it used to scroll the page according to the amount of my wheel turn. Now it does not. I went and built a complete separate installation of gnome and gnome apps using jhbuild system. I now have a second evince mlaks@Rashi:~$ /opt/gnome//bin/evince --version GNOME Document Viewer 3.11.3 and it has the same 'feature'. It does not scroll using the wheelmouse when positioned over the page. I note the following from google https://bbs.archlinux.org/viewtopic.php?id=162575 [SOLVED] What happened to evince? Hi all, I upgraded my system the other day and Evince seems to have disappeared, or at least been replaced by some other much more limited PDF viewer. All the toolbar buttons are different, there are no view settings and the mouse wheel no longer works when scrolling pages. Why was evince removed? It was a really good small PDF viewer. It seems that evince is indeed installed, but it's a completely different program to before. Do you know whether there was some major upstream change where they decided to change the whole UI and remove a bunch of features?? That seems a little odd. I have searched around a lot but there's no mention of evince changing which is why I'm so confused! Notice that the problem is marked [SOLVED]. Do you know what that individuals solution was? It was to forget about evince and use qpdfview instead. Which is dumb. On my machine, both the native evince mlaks@Rashi:~$ evince --version GNOME Document Viewer 3.10.0 and the newly build 3.11 from jhbuild both do not scroll on the page when I wiggle my mousewheel. I spend a lot of time reading pdfs and I love evince. Do I have to do a diff on the evince between the last working version to find out what changed or can someone just tell me why it worked in 3.4.0 and why it does not work in 3.11.3?
(In reply to comment #1) > Works here, so this looks like a debian specific problem. Try filing it on > bugs.debian.org. please see my comment 3
I apologize. It is not a evince bug. However it seems to be an important behaviour change. I need to understand the behavior change to see what to fix in my window manager stumpwm to support evince scrolling. I really love evince, and I really love stumpwm. I have further investigated the issue. I am running stumpwm. When I run other window managers (gnome lxde icewm etc) the behavior is correct with normal scroll with the mouse wheel. So my question is what is the change in the scrollwheel dependency between 3.4.0 to 3.10 and 3.11 that now the mousewheel does not scroll? I am sure that I will find other applications similarly affected as I use develop using gtk2-perl. Thank you very much! Mitchell
someone on stumpwm speculated whether it had to do with "export GDK_NATIVE_WINDOWS=1" not working. (evince:15963): Gdk-WARNING **: The GDK_NATIVE_WINDOWS environment variable is not supported in GTK3. See the documentation for gdk_window_ensure_native() on how to get native windows. does this make sense to the developers? someone reports that evince 3.10.3 works on NixOS in stumpwm with that environmental flag set although he seems to have a lot of gtk2 still around on his system.. Mitchell
More information common discussion: As far as we can tell it has nothing to do with GDK_NATIVE_WINDOWS, that was a red herring from the people at NixOS. Thus if I set GDK_NATIVE_WINDOWS=1 on debian stable (evince 3.4) we get the same error message, but the scrolling is fine. So it has NOTHING to do with GDK_NATIVE_WINDOWS. It definitely is a regression within only stumpwm caused by the switch of evince from 3.4 to 3.10.0 or 3.11.0 in debian. ie it is a switch from gtk2 to gtk3 that causes the problem. On icewm or gnome or openbox there is normal scrolling behavior. Moreover it is not an evince problem alone. It fully affects nautilus and eog and thus any program that is doing wheel scrolling. So what changed with wheel scrolling in the shift from gtk2 to gtk3 dependencies. It has been checked and is rrue on both debian sid and on arch linux and fedora 20. Thank you Mitchell Laks
It has been reported that this problem is reproducible with newer version of nautilus, eog and evince using stumpwm. http://lists.nongnu.org/archive/html/stumpwm-devel/2014-01/msg00013.html It seems to me the problem is in stupwm, gtk+, or somewhere else in the stack. I am reassigning to gtk+ (because the change in the smooth scrollwheel could explain this) in the hope that gtk+ might have better clues on where to look at, what to look, or just discard it is a problem in our side. Here is an interaction on #gtk+ channel: <gpoo> Company: do you have any idea of the behaviour described in https://bugzilla.gnome.org/show_bug.cgi?id=722157 ? I don't recall any changes in evince regarding to mousewheel, but maybe something in gtk+. <Services> Bug 722157: normal, Normal, ---, evince-maint, UNCONFIRMED, scrollwheel no longer scrolls pages while in continuous mode <gpoo> it seems the common root is stumpwm, but why evince could be affected if no changes has been made. <Company> gpoo: the only thing that changed wrt scrolling was that we started using the delta values of scroll events instead of doing one step per scroll event <Company> gpoo: no idea if that was in 3.8 or earlier (it wasn't 3.10, but the bug doesn't say what he upgraded from) <Company> gpoo: and iirc some X issues existed with it - drivers reported wrong values or something <Company> other than that, I don't know <Company> mclasen might though, he keeps better track of input-related changes than I do <Company> oh, he upgraded from 3.4 - it could definitely be smooth scrolling related then <Company> though I have no clue what stumpwm would do that triggers this <Company> i don't even know such a WM exists <daniels> the main issue with smooth scrolling is that we only report absolute values, rather than deltas, thanks to an xi2 design flaw <daniels> so you have to swallow the first event and compute deltas from then on in <Company> right <daniels> on an apple laptop (or someone else's, if they also have broadcom sensors), this makes no difference at all; on other laptops with shit synaptics pads (all of them), this isn't ideal but not catastrophic; on mousewheels, this definitely sucks <daniels> god only knows what stumpwm does if it requires native windows tho ... <Company> that doesn't explain why WM choice would trigger issues though <daniels> yeah, we don't have axis grabs or anything even remotely similar, so i'm not sure how stumpwm would be getting in the way <Company> unless it reconfigures input devices <gpoo> Company: thanks for the ideas. Neither did I know that such WM existed :-) <gpoo> and thanks daniels, we well. <gpoo> s/we well/as well/ <daniels> np <daniels> Company: i don't see how it would in such a way that would suppress smooth-scroll events tho <daniels> Company: unless it's got a top-level grab on all wheel events, and then synthesises them to replay down to the client <daniels> Company: but even then ... <daniels> whot would probably have a better idea; i just pop up every now and then to take the credit <Company> yeah, i can't come up witha good explanation either <Company> but so far we're just fishing for ideas Any idea?
The WM matters because those often set passive button grabs, and some of those on the legacy 4-7 scroll buttons to have some wm action on scroll events. When those button events are triggered, the pointer "leaves" and "enters" the application, this resets the calculated scroll deltas to 0, turning the scroll event the application gets immediately after into a no-op. This is a duplicate of bug #699574. *** This bug has been marked as a duplicate of bug 699574 ***