GNOME Bugzilla – Bug 108775
Support binding mouse buttons to actions
Last modified: 2021-07-05 13:47:28 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?
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 ***
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 buttons). 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.
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.
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 :)
s/on their (physical)/on their (physical) desktop/
Is future in another four years?
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. http://live.gnome.org/ThomasThurman
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.
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.
Well, let's say 2.21.3 and see how it goes.
I really wish I could bind <Alt>Button4 and <Alt>Button5 to raise and lower windows.
*** Bug 374601 has been marked as a duplicate of this bug. ***
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.
Note that dupe #374601 includes a patch for doing this, that's existed for over 2 years.
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.
Created attachment 186095 [details] [review] Metacity bind buttons (from 374601) This patch was provided by Thomas Thurman in https://bugzilla.gnome.org/show_bug.cgi?id=374601
> - 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 https://bugzilla.gnome.org/show_bug.cgi?id=647964
It's not clear whether it's even possible to bind basic mouse buttons to events anymore.
*** Bug 658353 has been marked as a duplicate of this bug. ***
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.
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).
I'm definitely still missing support for extra button mappings in Gnome/Gnome-shell.
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?
Having mouse buttons and keyboard shortcuts all done in the same way sounds reasonable to me.
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org 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 https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new ticket at https://gitlab.gnome.org/GNOME/mutter/-/issues/ Thank you for your understanding and your help.