Hello,
I recently enabled emulatewheel in X on my laptop, which is really cool.
It's a thinkpad, so the buttons are in this sort of funky layout:
[1][3]
[ 2 ]
So now button 2 is set to emulatewheel, which means it generates events
for buttons 4 5 6 and 7, which I have mapped to the X and Y axes. I now
get horizontal and vertical scrolling just using the touchpoint nipple,
which is cool! The great thing about the thinkpad layout is that it's
since buttons 1 and 3 are right next to each other, they're really easy
to hit together with a single thumb, so Emulate3Buttons restores the missing
button 2 functionality near-perfectly.
So all right, I'll get to the question, already. =)
My current mapping looks like this:
Option "Emulate3Buttons"
Option "EmulateWheel" "on"
Option "EmulateWheelButton" "2"
Option "XAxisMapping" "6 7"
Option "YAxisMapping" "4 5"
This allows me to scroll as expected in Mozilla: moving the nipple to
the right scrolls right, moving to the left scrolls left. The problem
is that xpdf works backwards. I'm trying some testing to see how
various apps respond to buttons 6 and 7. Mozilla maps button 6 to
scroll left (meaning pan viewport left, moving content to the right).
Xpdf does the opposite (content moves left, meaning viewport moves
right). I'm trying on fvwm these days, and I'm using those buttons to
scroll around the virtual desktop, but they do only as I say in my
fvwm2rc, so that's not a good test. OOo does nothing on buttons 6 and
7. gucharmap uses 6 => scroll left (just like mozilla; my guess is that
this is gtk behavior and all gtk apps will behave the same). Emacs21
just beeps at me for any of buttons 4 5 6 or 7. There, same as fvwm,
the buttons are all configurable, so I could make it do the right thing,
but it doesn't give me any extra information about what is the "right"
way. So far, the only thing I've seen using 6 for scroll right is xpdf,
so I'm inclined to think that it's wrong. I would suspect that this is
not isolated to the one program, though, and is a characteristic of a
library, and that any programs that use this library will also behave
the same (similar to my suspicion about gtk). Woops, just tried the
gimp, and it doesn't do anything on buttons 6 and 7, so maybe it's not
universally gtk behavior.
My question is "where does the bug get filed?" I think even if there is
no "standard" here, it would be the Right Thing for all programs in
Debian to scroll the same way for the same mouse events. In this case,
it seems like the Right Thing would just be determined by popularity; if
only xpdf is doing it one way and everything else the other way, it
seems like it would be a lot easier to patch just xpdf instead of
everything else.
good times,
Vineet
--
http://www.doorstop.net/
--
"Extremism in the defense of liberty is no vice.
Moderation in the pursuit of justice is no virtue." -- Barry Goldwater
Attachment:
pgpK0wpZlql1X.pgp
Description: PGP signature