On Sun, 2014-01-19 at 18:54 +0100, yggdrasil gmx co uk wrote:
Germán Póo-Caamaño <gpoo gnome org> writes:On Sat, 2014-01-18 at 13:20 +0100, yggdrasil gmx co uk wrote:Germán Póo-Caamaño <gpoo gnome org> writes:I think my point is: You assumed that a bug in your installation was made on purpose. Instead of asking for that or reporting a bug, you preferred to spread the word that was a decision of GNOME developers to change the mouse wheel behaviour only for Evince.Of corse not. You're not reading me right, deliberate or not. Apologies if I was unclear. I mean that things change. Develop. Evolve. There is a reason for that, surely. Just as surely as there's no conspiracy to maim the mouse wheel by Evince developers. Probably it works for most. Maybe even all but me. I would check this furhter if I had the time. I am quite sure it's a corner case.
Thanks for clarifying what it seems to be a miscommunication on one or both ends.
Please, report the bugs or ask whenever something stop working for you. It could be a combination of factors that triggers a bug or a honest mistake. And when you do that, please give as much as detail of the steps to reproduce it.I have done some basic testing and it appears to be the combination stumpwm + evince that doesn't get along. I have a base F20 install. Running LXDE and evince, the mouse wheel works. Switching to stumpwm + evince, the mouse wheel no longer scrolls. Only in evince however, Okular, Firefox etc. is ok. Even the file chooser dialogue (when opening a file) doesn't work from evince, but works from other applications (scrolling with mouse wheel that is) (under stumpwm). In the previous version of evince, there was no problem with the mouse wheel, regardless of window manager. To repeat: 1. Install Fedora 20 2. Install stumpwm 0.9.7.80 3. Open evince 3.10.3 and try scrolling with mouse wheel
There has not been changes in Evince with scrolling wheel, but in gtk+. See what a gtk+ and X developer had to say about it: <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 -- Germán Poo-Caamaño http://calcifer.org/
Attachment:
signature.asc
Description: This is a digitally signed message part