(Guessing at the component.)
For the kiosks at DNA Lounge, I need to re-bind all three mouse
buttons to behave as button1. You can read the rationale for
this at http://www.dnalounge.com/backstage/src/kiosk/#usability
With NS4, this is easy: I just edit the Motif resources like so:
With GTK programs, this is easy: I just use $GTK_MODULES like so:
I'm told that there's no way to accomplish this simple task
This is probably a dup -- certainly a much wished-for feature -- but I don't
know the other bug number offhand. Mouse events weren't included in either the
XUL key handling or the XBL key handling. As a workaround, you could explode
the jar files and edit the JS to add mouse handlers, e.g. see contentAreaClick.js.
This looks like a dup of 133529, but I'm not sure. Would using a one-
button mouse be an option for the short-term?
> Would using a one-button mouse be an option for the short-term?
Unfortunately, no. There are no one-button trackballs, let alone
one-button trackballs that are both inexpensive and sufficiently
hardened that they can be bolted down in a public place and last
longer than a day when drunk people are about. The trackballs
I found are pretty nice -- they're $20, they light up when you
press the buttons, and it's impossible to remove the ball without
taking screws out. With most trackballs, the balls aren't really
attached, which means they'd be bouncing around the room all
Using Netscape 4.78 forevermore is a perfectly acceptable
workaround, however. I reported this bug because this is
a showstopper for me even *trying* to use Mozilla on my
"you could explode the jar files and edit the JS to add
mouse handlers" sounds hard/intimidating/fragile/not-fun,
so I think I'll pass on that.
You could explode the trackballs and wire each button to send the same
electrical signal as mouse1. Does that also sound
I like the idea of putting duct tape over the other buttons.
Good ol' duct tape.
> You could explode the trackballs and wire each button
> to send the same electrical signal as mouse1.
I thought about that, but it looks like it would be
pretty difficult (I'd have to solder directly on the
circuitboard, and it's pretty tight in there.)
Plus, we *do* have to replace these things every now
and then, and it's already a big hassle to get them
in and out (lots of threading of cables through tight
spaces) and I don't need to add another hour of labor
on top of that each time one breaks.
Besides which -- come on, man! It's solvable in
software with both GTK and Motif. Your honor is at
stake here. Do you want all the kids on the playground
to laugh at you because Mozilla so worthless and weak
that it requires hardware support?
blizzard, how hard would it be for us to properly support emission hooks such as
onebutton.c uses? It looks like the reason it doesn't work as-is is that we
hook directly into the gdk mainloop for event processing (before gtk has had a
chance to run the event through the hook function).
The problem is that the inner windows aren't attached to any particular widget.
That's why the theming solution doesn't work out of the box.
Let me look into the emission hook - that's a decent idea. It might be possible.
Can you use a variant of this?
xinput set-button-map Mouse1 1 1 1
> Can you use a variant of this?
> xinput set-button-map Mouse1 1 1 1
I don't know what xinput is (I have no such program)
but the very first thing I tried was:
xmodmap -e 'pointer = 1 1 1 1 1'
which causes a BadValue in XSetPointerMapping.
Apparently the X server believes that the pointer
map must contain only 1:1 values: you can't use
it to map N buttons to <N.
-> blizzard, reassign as needed
Jamie, try mapping button 2 to button 4 and button 3 to button 5 (mousewheel).
If it works, maybe that is an acceptable workaround...?
> Jamie, try mapping button 2 to button 4 and button 3 to button 5 (mousewheel).
> If it works, maybe that is an acceptable workaround...?
Not to speak for Jamie, but he needs all 3 buttons to behave as button one for
his kiosks... Binding mid/right buttons to 4/5 would just make those two
buttons not work (or scroll the window, depending).
have you tried http://hocwp.free.fr/xbindkeys/xbindkeys.html ?
supposedly it works for mice too.
I don't see how xbindkeys could possibly help.
Created attachment 84533 [details] [diff] [review]
Here is a small patch to add "111", "222", and "333" to the list of legal
button sequences in gpm. The seq array (in gpn.c) maps the value of the -B
argument to what amounts to a button translation table. The new entries
translate any button state (except "all up") into a single button.
With this patch, I can start gpm with...
$ gpm -t ps/2 -m /dev/mouse -B 111 -R msc
... to map all buttons to the first, and repeat in Mouse Systems speak on
after changing my mouse settings in XF86Config-4 to...
... I was able to start X and have my three button mouse act like one of those
expensive ones from Apple.
The catch is that *sometimes* the cursor wouldn't move *at all* after starting
X. I don't think this has anything to do with the patch. Could have something
to do with the version of gpm I hacked vs. the version of X I'm using, 4.1.0,
or something. In any case, once I got it to start ok, it seemed to stay ok.
still it would be *very* nice to have a way to redefine mouse buttons
(well and keyboard shortcuts) freely - similar to how it was possible with NS4.
Is there the technical possibility to do that or was this completely
ignored when mozilla was designed?
Created attachment 84683 [details] [diff] [review]
Patch that adds a call to a sniffer module.
Created attachment 84685 [details]
sample munger module
Sample module that will munge events properly.
Ok, I worked around this Mozilla deficiency by using a hacked version of gpm to
re-map the mouse buttons before X sees them (thanks to everyone who helped with
that.) So I have a solution for my kiosks. But I still think it's extra, extra
silly that Mozilla has no user-accessible mouse keymap, so don't go closing this
on my account!
*** Bug 152951 has been marked as a duplicate of this bug. ***