After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 108775 - Support binding mouse buttons to actions
Support binding mouse buttons to actions
Product: mutter
Classification: Core
Component: general
Other Linux
: Normal enhancement
: ---
Assigned To: mutter-maint
: 374601 658353 (view as bug list)
Depends on:
Blocks: 155457
Reported: 2003-03-19 19:13 UTC by Jeremy Nickurak
Modified: 2021-07-05 13:47 UTC
See Also:
GNOME target: ---
GNOME version: Unversioned Enhancement

Metacity bind buttons (from 374601) (6.79 KB, patch)
2011-04-16 19:31 UTC, Jeremy Nickurak
none Details | Review

Description Jeremy Nickurak 2003-03-19 19:13:01 UTC
Metacity's key-binding mechanism already appears very robust. However, just
as keyboards are expanding with a flurry of additional useful keys, some
mice are getting equally complex. New mouse models from Microsoft and
Logitech have included additional buttons for some time now, and it's only
natural that these buttons receive support somewhere.

What would be involved in adding something like "<Button6-Click>" as an
example of syntax in the gconf key, to specify mouse events?
Comment 1 Havoc Pennington 2003-03-19 19:32:44 UTC
The X protocol only supports 3 buttons (buttons 4 and 5 are in the
protocol but are used to mean "scroll wheel")

So basically to support more than 3 buttons you would need to 
use the X input extension (used for joysticks and drawing tablets and
such), which would be fairly involved. Also, making clicks 
configurable is fairly hard implementation-wise to get right, because 
mouse clicks don't really map to one-shot actions for the most part,
they map to more complicated blocks of code that need to refer to the 
button number in more than one place over time.

Anyhow, I might consider a patch that did things in a sufficiently
nice/robust way, but I wasn't able to come up with such a patch
myself, so I think it's fairly hard. I think the feature is pretty low
priority anyhow.

*** This bug has been marked as a duplicate of 83210 ***
Comment 2 Jeremy Nickurak 2003-03-21 02:32:55 UTC
Havoc: that's news to me.. I've been using 4 button + wheel logitech
mice for at least a couple years just fine. The fourth button actually
comes through as button 6, after a button mapping to keep the scroll
wheel on 4/5 for gtk & other mousewheel-watching applications. This
has been under sawfish, where bindings to the 4th mouse button work as
cleanly as bindings to any other button (including the scroll wheel

Re-opening for the moment, since the bug you referenced seems to deal
with a couple of very specific button bindings, and has been marked
fixed, whereas the more general issue raised here still exists.
Comment 3 Havoc Pennington 2003-03-21 02:51:57 UTC
You're right, event->button can be > 5, but buttons > 5 aren't in 
event->state. metacity only uses the state mask in one place.

Still, it's not an easy patch to write.
Comment 4 Jeremy Nickurak 2003-05-09 23:16:28 UTC
I just wanted to clarify my reasons for wanting this feature, as it's
the only thing that's really holding me to sawfish at this point,
despite a few glaring problems in other areas.

The configuration I use with the mouse buttons is the single most
imortant thing to my window manager choice, and I've gotten a few
other people sold on this particular setup as well.

In the context of a window's titlebar, the first button (almost
universally) controls window movement across the X and Y values
accessable to it. Other tasks of window organization & management have
followed, in the form of the maximize, mimize, shade, and other
similar, less popular features. It seems only natural to me that the
movement & management of a window's position along a third axis (the
workspaces) would fall to the same context.

This is precisely the setup I use. Buttons 4 and 5, the scroll wheel,
in the titlebar move a window back and forth among the available
workspaces. (In my case, it also creates new workspaces when
neccesary.) In combination with the mapping of the scrollwheel to
workspace switching in the root window, I have an ability I'm no
longer willing to give up easilly: I can completely manage my window's
position in X, Y, and workspaces without contantly moving my hand back
and forth between the keyboard and mouse.

With newer mice having even more buttons (and additional wheels), the
amount that a user has to gain in terms of localizing related
functions in a single location on their (physical) is really
phenominal, IMO.

Anyways, that about covers it :)
Comment 5 Jeremy Nickurak 2003-05-16 20:38:07 UTC
s/on their (physical)/on their (physical) desktop/
Comment 6 deadowlsurvivor 2007-06-09 10:01:29 UTC
Is future in another four years?
Comment 7 Thomas Thurman 2007-06-11 03:19:52 UTC
I'd imagine GTK's moved on a way since then, though I don't know for sure. I'll ask around and put this bug on my to-do list.
Comment 8 deadowlsurvivor 2007-06-11 04:06:24 UTC
I don't know, the last I heard the latest release of metacity contained code for configuring right and middle mouse buttons. I don't know about left mouse buttons and scroll wheel actions, along with any extra buttons. I think I might have actually submitted a duplicate of this that got rejected.
Comment 9 daedalusman 2007-11-13 04:29:18 UTC
How is the progress with this bug going? I would really love to see this functionality in metacity. As far as I know metacity is the only WM that doesn't allow one to use the scroll wheel on the desktop to switch workspaces and it's one of the most useful features of a window manager under linux. Thanks.
Comment 10 Thomas Thurman 2007-11-13 04:48:22 UTC
Well, let's say 2.21.3 and see how it goes.
Comment 11 Nick Welch 2009-01-09 16:20:33 UTC
I really wish I could bind <Alt>Button4 and <Alt>Button5 to raise and lower windows.
Comment 12 Jeremy Nickurak 2010-06-25 23:12:18 UTC
*** Bug 374601 has been marked as a duplicate of this bug. ***
Comment 13 Jeremy Nickurak 2010-06-25 23:17:08 UTC
Wow, 7 years later :)

Compiz, among other window managers, has really given users a lot more configuration ability since this bug opened, and hardware keeps getting more features for desktop use, and it would be great to have access to it here.

Three things metacity seems to lack: (correct me if and where i'm wrong)
- The ability to bind multiple events to the same action. I should be able to have a keypress and a button press that do the same thing.
- The ability to bind high-numbered mouse buttons, as well as double-click events for mouse buttons.
- The ability to indicate context more finely. Metacity has global and in-application right now. "Desktop" is important too, but others like "Titlebar" would be really nice.
Comment 14 Jeremy Nickurak 2011-04-11 23:14:50 UTC
Note that dupe #374601 includes a patch for doing this, that's existed for over 2 years.
Comment 15 Jeremy Nickurak 2011-04-16 19:24:04 UTC
Per discussion in #bugs, reassigning to mutter where it's equally effected. Maybe this is more relevant in a different gnome-shell component though?

This bug affects gnome-shell more directly than it did metacity. With metacity, one at least had the option of swapping a different WM, whereas under gnome-shell you can't do that without throwing out the baby with the bath water.
Comment 16 Jeremy Nickurak 2011-04-16 19:31:29 UTC
Created attachment 186095 [details] [review]
Metacity bind buttons (from 374601)

This patch was provided by Thomas Thurman in
Comment 17 Jeremy Nickurak 2011-06-14 22:31:33 UTC
> - The ability to bind multiple events to the same action. I should be able to
have a keypress and a button press that do the same thing.

FWIW, I've filed this seperately as
Comment 18 Jeremy Nickurak 2011-06-23 05:24:17 UTC
It's not clear whether it's even possible to bind basic mouse buttons to events anymore.
Comment 19 Florian Müllner 2011-09-06 13:04:12 UTC
*** Bug 658353 has been marked as a duplicate of this bug. ***
Comment 20 Jasper St. Pierre (not reading bugmail) 2014-12-29 07:06:02 UTC
Is there still a want for this? It would be a considerable amount of work with questionable semantics and utility, but I can do it if you want it.
Comment 21 Steve Hill 2014-12-29 08:06:04 UTC
I am still be interested in this - I used to use the extra 2 buttons on my mouse for quick window raising and lowering and miss this feature.

That said, I am starting to look for alternatives to Gnome, as the recent loss of support for window shading has seriously harmed the usability (which is a shame because in most other ways Gnome 3 is about the best system I've used to date).
Comment 22 Jeremy Nickurak 2014-12-29 22:29:00 UTC
I'm definitely still missing support for extra button mappings in Gnome/Gnome-shell.
Comment 23 Jasper St. Pierre (not reading bugmail) 2014-12-30 02:10:12 UTC
How would you like to see it done? Would you like to see actions in the Keyboard Shortcuts panel bindable to <Ctrl><Alt>Button_1 or similar? Or would the set of button bindings be separately defined from key bindings?
Comment 24 Steve Hill 2014-12-30 18:59:57 UTC
Having mouse buttons and keyboard shortcuts all done in the same way sounds reasonable to me.
Comment 25 GNOME Infrastructure Team 2021-07-05 13:47:28 UTC
GNOME is going to shut down in favor of
As part of that, we are mass-closing older open tickets in
which have not seen updates for a longer time (resources are unfortunately
quite limited so not every ticket can get handled).

If you can still reproduce the situation described in this ticket in a recent
and supported software version, then please follow
and create a new ticket at

Thank you for your understanding and your help.