stumpwm + gtk+ smooth scrolling issue (was Re: [evince] The missing menu bar)

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

stumpwm + gtk+ smooth scrolling issue (was Re: [evince] The missing menu bar)

yggdrasil
That dialogue indeed gave some interesting info, thanks for finding this
out. This topic also appeared just recently on the stumpwm list, and it
seems also eog and nautilus are affected.

So this smooth scrolling may be the issue. I'll cc this to the stumpwm
list, maybe it can give some leads.

Germán Póo-Caamaño <[hidden email]> writes:

> 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

_______________________________________________
Stumpwm-devel mailing list
[hidden email]
https://lists.nongnu.org/mailman/listinfo/stumpwm-devel