Bug 96431 - Improve Wayland mouse button support for shortcuts in KHotkeys
Summary: Improve Wayland mouse button support for shortcuts in KHotkeys
Status: RESOLVED UNMAINTAINED
Alias: None
Product: systemsettings
Classification: Applications
Component: kcm_khotkeys (show other bugs)
Version: unspecified
Platform: Compiled Sources Linux
: NOR wishlist
Target Milestone: ---
Assignee: Michael Jansen
URL:
Keywords:
: 178633 (view as bug list)
Depends on:
Blocks: 192867 226370
  Show dependency treegraph
 
Reported: 2005-01-06 12:04 UTC by Ismail Donmez
Modified: 2023-08-06 22:39 UTC (History)
48 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Ismail Donmez 2005-01-06 12:04:31 UTC
Version:            (using KDE Devel)
Installed from:    Compiled sources
OS:                Linux

I would like to be able to assign my mouse's sidebuttons for shortcuts. Namely the 8th,9th buttons used for Back/Forward actions.
Comment 1 Lubos Lunak 2005-07-20 14:57:33 UTC
*** Bug 109374 has been marked as a duplicate of this bug. ***
Comment 2 Stefan Monov 2006-02-13 23:01:46 UTC
A program exists to do about the same, it's called imwheel ( http://imwheel.sf.net ). All we need is a kcontrol module for it, I think.
Comment 3 Lubos Lunak 2006-08-25 14:38:42 UTC

*** This bug has been marked as a duplicate of 48062 ***
Comment 4 Lubos Lunak 2007-04-18 12:09:14 UTC
This is not a duplicate, bug #48062 asks for mouse buttons to act as modifiers.
Comment 5 Lubos Lunak 2007-06-04 12:50:36 UTC
*** Bug 98778 has been marked as a duplicate of this bug. ***
Comment 6 Stefan Endrullis 2007-10-23 13:23:49 UTC
I would appreciate if you implement the configuration of shortcuts with the possibility of combining keyboard key with mouse buttons, whereas a mouse button can be a normal mouse button (left, right, ...) or WheelUp or WheelDown.
Comment 7 David 2007-12-15 13:24:08 UTC
This really needs to be implemented, currently it only allows keyboard shortcuts.

What we also need is not only ctrl, alt, shift to be modifiers, but any any combination of keys should work (like instead of just ctrl+b, a+b keys). And same with mouse buttons
Comment 8 Todd 2008-09-17 19:34:07 UTC
I think this really needs to be implemented for KDE4.  But rather than have it be for just mouse and keyboard, make it so anything can be used.  For instance if you have lirc installed it will allow you to use buttons from your remote.  If you have a bluetooth remote or have your cell phone set up as a bluetooth controller then you can use those buttons.  Basically make it so that instead of being for keyboard shortcuts, they can be shortcuts for anything that sends button presses of any kind.  That way you don't need a separate configuration program for lirc, bluetooth, your mouse, and your keyboard, everything can be controlled through a single interface.
Comment 9 lucas 2008-11-29 04:05:21 UTC
*** Bug 171295 has been marked as a duplicate of this bug. ***
Comment 10 lucas 2008-11-29 04:05:39 UTC
*** Bug 176392 has been marked as a duplicate of this bug. ***
Comment 11 lucas 2008-11-29 04:09:13 UTC
*** Bug 156082 has been marked as a duplicate of this bug. ***
Comment 12 lucas 2008-11-29 05:34:57 UTC
*** Bug 168771 has been marked as a duplicate of this bug. ***
Comment 13 lucas 2008-12-24 05:12:55 UTC
*** Bug 178633 has been marked as a duplicate of this bug. ***
Comment 14 Michael Höller 2009-01-21 08:51:07 UTC
Hello this is really missing in KDE4, this function is standard in compiz and may drives may users away from KWin Effects since it is so much more handy to use when you can do something like: STRG+MIDDLE MOUSE BUTTON to directly rotate = change Desktop screen.

Comment 15 simon 2009-02-12 14:01:23 UTC
any news on this one?
Comment 16 Andreas Velten 2009-02-14 20:51:52 UTC
I had compiz set up to open and drag the cube by just pressing and holding the middle mouse button (i.e. the wheel) without any key. That should be possible here too.
Comment 17 alex 2009-02-14 21:00:05 UTC
Would be great for scrolling to zoom in the desktop as well. For example with Compiz I had alt+scroll up/down to zoom in/out - was a great usability feature for me.
Comment 18 Steffen Schloenvoigt 2009-06-30 23:14:12 UTC
Something new on this issue ? Last comment is from february.
I'd really like to have meta+scrollwheel zoom.
Comment 19 Martin Flöser 2009-06-30 23:33:49 UTC
(In reply to comment #18)
> Something new on this issue ? Last comment is from february.
> I'd really like to have meta+scrollwheel zoom.
Yes there is something new. There is a GSoC project going on for adding mouse plugins to Plasma desktop. It won't be a global shortcut as you have to be on the desktop, but better than nothing ;-)
Comment 20 simon 2009-06-30 23:40:44 UTC
limited to the desktop? this sounds lame and breaks the workflow.
even though i appreciate the efforts i hope this will evolve to a global shortcut solution
Comment 21 Martin Flöser 2009-06-30 23:47:14 UTC
(In reply to comment #20)
> limited to the desktop? this sounds lame and breaks the workflow.
> even though i appreciate the efforts i hope this will evolve to a global
> shortcut solution
Global mouse shortcuts will cause problems as that will break applications. E.g. ctrl+lmb on a link in Konqueror will open the linked webpage in a new tab. If you add a global shortcut this will break :-(

Yes I know that the same situation applies to keyboard shortcuts, but the possible combinations with modifiers and mouse buttons is quite limited
Comment 22 Matt Whitlock 2009-07-01 00:09:27 UTC
Yes, but I should be able to assign mouse button #8 to Konqueror's "Back" action, and I should be able to assign mouse button #10 to the "Present Windows" global shortcut.

Not all mice have only three buttons.  Right now I have to use xbindkeys to execute xte to simulate key presses when I click buttons on my mouse, and then those simulated key presses get interpreted by KDE's shortcuts support.  Kind of going around my ankle to get to my thumb, wouldn't you say?
Comment 23 simon 2009-07-01 09:19:22 UTC
Ctrl+a is already broken if a kate part is embedded in konqueror, eg when showing a patch here in bugzilla. So giving the window in focus/active/lastused the priority when such a clash happens and allowing to resolve the doubled shortcut would be a way to go.
So this is no argument for simply dropping global Shortcuts involving the mouse.
Comment 24 Stefan Endrullis 2009-07-01 10:30:11 UTC
I'm not sure how it is implemented in KDE4, but in KDE3 every application has its own (local) shortcut configuration and kcontrol allows you to assign global shortcuts to various actions. Of course it's possible to produce conflicts via global shortcuts, but that's definitely not a problem, since you can bind those global shortcuts to certain conditions (e.g. window name has to match "kaffeine"). At least that is the case in kcontrol of KDE3.

BWT I would appreciate when shortcuts with mouse buttons would be available to global AND local shortcuts.
Comment 25 Kamil Neczaj 2009-07-01 23:14:05 UTC
(In reply to comment #21)
> (In reply to comment #20)
> > limited to the desktop? this sounds lame and breaks the workflow.
> > even though i appreciate the efforts i hope this will evolve to a global
> > shortcut solution
> Global mouse shortcuts will cause problems as that will break applications.
> E.g. ctrl+lmb on a link in Konqueror will open the linked webpage in a new tab.
> If you add a global shortcut this will break :-(
> 
> Yes I know that the same situation applies to keyboard shortcuts, but the
> possible combinations with modifiers and mouse buttons is quite limited

You may be suprised, but the problem is that shorcuts configuration doesn't include mouse buttons. If mouse buttons were be included in configuration, the conflicts between them would be checked.

There is also another problem. When local hotkeys are set, kde checks whether they conflict with global hotkeys, but not in the other side. If the user sets global hotkeys using systemsettings, kde doesn't check for conflicts with the local ones.
Comment 26 Kamil Neczaj 2009-07-01 23:15:38 UTC
There should be some kind of database with local shourtcuts to check conflicts when setting global ones.
Comment 27 damian pereira 2010-09-28 08:43:54 UTC
Why not just enable global/local shortcuts or modifiers only for extra mouse buttons (not 1 or 2 or wheel). AFAIK the extra mouse buttons aren't used by default in any app, so they should make no conflict, except it's an user created one.
Comment 28 marsu1 2011-05-17 00:43:50 UTC
Anything new on that? For me it would be enough if Dolphin would support mouse buttons to navigate forward or back...
Comment 29 Christian H 2011-05-31 09:20:39 UTC
Yay, This would a pritty nice feature :/.
I have the same Problem.
Comment 30 Rick Stockton 2011-08-02 05:42:26 UTC
The description talks about using only "BACKBUTTON and "FORWARDBUTTON", which CAN be done since Qt 4.7 - If the Programmer chooses to execute code upon the occurrence of Events from these Buttons.

Qt made a strange choice in naming them as "XButton1" and "XButton2"; These buttons (Raw Button 8, and Raw Button 9) are widely understood to be "Back" and "Forward", respectively.
---- 

The purpose of my post this evening, however, is to State that I can "fix" Qt/x11. With relatively easy code and namespace changes, Qt can emit MouseButtonPress, MouseButtonRelease, and MouseButtonDoubleClick ** FOR ALL 32 POSSIBLE MOUSE BUTTONS **. And, a "Release" containing this code will remain backward-compatible with code compiled against earlier Releases of Qt 4.x (No re-compile would be needed needed.)

I can almost certainly add a new function to provide a full-width Mouse Button StateMask, as well. And so: If YOU want to define "Global Shortcuts" in KWin, or you want to program multi-button Mouse codes into a program you're writing, or you want to create special key+button codes, you can do it by invoking the 'READ' function on the ButtonStateMask when your keystroke event arrives.

You will get the mask AT THAT MOMENT. And so, even if the mouse button has been held down from "outside", before entering your widget, you can see that it's down without getting an interrupt. With this knowledge, your program can execute any branch/control structure you care to write for that combination.

This also holds for multiple concurrent mouse buttons. For example: The combination of "Button13" double-clicked, with RIGHTBUTTON held down when the ButtonDblClick Event is issued, can be made to invoke different code than "Button13" alone. With a gamer-type Mouse, like my own Logitech G700, you could define *dozens* of unique shortcuts. And they'd all be executable with the right hand only, with no need to reach for the Keyboard.

If you all can establish the necessity of this "enhancement/fix" with the Qt people, the code for x11 is easy.
Comment 31 Gastón M. Tonietti 2011-11-23 20:05:44 UTC
Would be really nice to have it.
Comment 32 Maciej Pilichowski 2011-11-24 09:33:33 UTC
"If you all can establish the necessity of this "enhancement/fix" with the Qt
people"

How we could convince Qt people that handicapped people do exist, and the more severely you are injured the more useful A18Y features are? After all it is by definition, that is what A18Y is.

Does anyone know the appropriate Qt people addresses or something, to remind them about such simple facts?
Comment 33 Todd 2011-11-24 23:01:49 UTC
The enhancement/fix has already been submitted to Qt.
Comment 34 Rick Stockton 2011-11-25 08:54:11 UTC
Todd: my comment 30, of course, refers to complicated stuff which I haven't written yet-- and there are limitations concerning HOW I am allowed to do it. (I can thnk of an easy, low-level way, but it would definitely get a fatal "-2" Code Review Score from the Qt Core Release Mgr ;)
---

Maciej- I think that you're spamming, a little bit. THIS bug is going to result in keyboard/mouse/shortcut enhancements, your excellent argument belongs in 48062 (and you already put it there, thus my "spam" accusation.) Who to contact? Well, Qt Development is undergoing some difficult reorganizations these days, I'm afraid that the most effective person to PING! about these issues is.... me.
And I can't 'direct' Qt; all I can do is write code, submit it, and convince Qt Mgmt. (and other coders) of it's value after I've given them something to look at.

You did a great job of getting my attention, your argument is solid, and I won't forget the issue. But the most likely situation still has me unable to re-open 48062 and work on the time frame which it would need. I'm an unpaid and relatively inexperience volunteer, the hours which I spend with Qt and KDE are stolen from a very limited pool of "free time". Maybe I will be able to re-open 48062, but that's not looking very likely right now. And so, rather than encourage too much "Hope" by leaving as an "Active", Assigned Wish, I closed it. Honesty is the best policy, I think.

Comment back on 48062, if you want to suggest ideas for helping one-handed users. Let's keep this one focused on the shortcut system.
Comment 35 Rick Stockton 2012-01-14 19:27:28 UTC
I'm working on the Qt pre-requisite enhancements. I might be able to finish in time for Qt 5.0, but have only about two weeks of time to do this. If unable to finish the job, then the Qt portions (a QMouseShortcutMap class, and so on) will be delayed until Qt 5.1.
Comment 36 Rick Stockton 2012-01-26 19:26:21 UTC
I did not have time to complete this before the API freeze date of Qt 5.0. The Qt prerequisite classes, therefore, will not appear before Qt 5.1.

Sorry, everyone, but I'm an unpaid "pure volunteer", with very limited time and C++ coding skills.
Comment 37 Rick Stockton 2012-08-14 18:16:05 UTC
Status update for you interested bug watchers:
I am now working on "mouse shortcuts" for Qt 5.1. (The PREREQUISITE for this enhancement). If I accomplish everything I want, then a "MouseShortcutSequence" will be any unique combination of the following Mouse Event characteristics:

1. Qt::MouseButton "button" (the button being released, pressed, or double-clicked). I don't know of a current mouse device with more than 15 "buttons", plus the 4 wheel scroll directions (which don't count as buttons in Qt.) And, in various OS choices you might be limited to fewer buttons. (Blackberry; and IIRC, Apple OS-X; definitely less on Windows.)

2. Type of button event (Release, Press, or DoubleClick): I'm hoping to allow Shortcuts and Actions based on "Press" Events to support the "Repeatable" property. You won't want to have shortcuts for both "ButtonPress" and "ButtonRelease", unless you want to do both things. (In Qt a "click", which drives nearly all of the Mouse-Based UI events, corresponds to the hardware "ButtonRelease" -- not the "Press".) If I can't make "repeatable" work, then I won't support 'Press' events - just 'Release' and 'DoubleClick'.

3. Qt::Keyboard Modifiers (Useful if you've got two hands). NO OTHER KEYS, I'm only going to support the Modifiers. You can none at all, just one, or any combination, e.g. Qt::ALT+Qt::SHIFT. 

4. Qt::MouseButtons "Held Buttons": As withthe  keyboard modifiers, you can hold any combination combination of ButtonLeft, ButtonRight, ButtonMiddle (or none of them), as long as the main "button" is a different button. These 3 buttons can be "mouse modifiers" for events on other buttons.
- - - - -
This allows for a lot of different combinations. For example, here's just a few of the shortcut "Mouse Sequences" which could define with just button = Qt::ForwardButton (i.e., an everyday Back+Forward sidebutton mouse, which is fully supported on all platforms):

ForwardButton clickled with LeftButton held down;
ForwardButton clickled with RightButton held down;
ForwardButton clicked with Qt::ALT held on the keyboard;
ForwardButton clicked with Qt::SHIFT held on the keyboard;
ForwardButton clicked with Qt::SHIFT *and* Qt::ALT held on the keyboard;
ForwardButton clicked with Qt::SHIFT held on the keyboard, and LeftButton held on the mouse;
+ All of those with Forwardbutton doubleclicked, instead of single-clicked;
+ All of those which used Qt::SHIFT, (including those 'doubleclick' combinations) but replacing Qt::SHIFT with Qt::CTRL instead .....
+ All of those, but with Qt::MiddleButton held down;
+ All of those, but with BOTH Qt::LeftButton and Qt::RightButton held down;
+ many, many other combinations.

A "high-end" mouse, like my Logitech G700, is capable of defining about 40 "comfortable" one-handed sequences for me, because I find it difficult to hold MiddleButton. (And because some of the other combinations would stretch my thumb too much.) But I'm lucky to be two-handed, so every one of those can be modified to add a combination of QT::SHIFT || QT::ALT || QT::CTRL (6 possible combinations, just with these 3 modifiers.) That provides the possiblity of about 240 comfortable combinations, on just ONE of my seven "extra" buttons. My own number of possible "Mouse Shortcut Sequences" numbers, all reasonably comfortable for me to execute, exceeds 1400.

With a Razr "Naga", I'd have lots more (it has 12 "extra" buttons, instead of 7). With a high-end mouse, on any flavor of Linux, QNX, or Apple, you're probably going to run out of human memory capability (what the heck was that shortcut???) long before you run out of usable mouse + keyboard modifer combinations.

Right now, it's many months before any possible Release of Qt 5.1. But I've got a plan, and I'm working on it!
Comment 38 Rick Stockton 2012-08-17 21:28:54 UTC
*** Bug 276413 has been marked as a duplicate of this bug. ***
Comment 39 Rick Stockton 2012-08-17 22:37:43 UTC
*** Bug 193349 has been marked as a duplicate of this bug. ***
Comment 40 Rick Stockton 2012-08-17 23:32:11 UTC
*** Bug 226370 has been marked as a duplicate of this bug. ***
Comment 41 Rick Stockton 2012-08-17 23:36:45 UTC
(In reply to comment #40)
> *** Bug 226370 has been marked as a duplicate of this bug. ***
No - that bug is for the khotkeys GUI, and this bug is prerequisite (bnut not the same bug)
Comment 42 Rick Stockton 2012-12-21 05:04:31 UTC
Within Qt the Performance cost, and added maintenance headache, is unnaceptable -- especially since deriving 'QMouseSequence' from 'QKeySequence' would do nothing for QML. With both Widgits and QML, mouse focus "reaches back" into parent widgets and QML MouseAreas, ultimately (if no one accepts the event) reaching KWin anyway.

I am discontinuing work on this, WRT enhancement to Qt5. Whether KDE should have Desktop shortcuts and GUI, with Human Interface Guidelines for using exotic mouse button combinations (i.e., press of one button, with drag, while holding another ... or using high-numbered buttons on non-traditional way) ...  I will leave to KDE Developers who understand KDE shortcuts better than I do.
Comment 43 Rick Stockton 2012-12-27 06:42:18 UTC
Providing more detail:

The 'scope of work' to make _genuine_ mouse shortcuts within Qt (translating mouse events into shortcut events, using new Classes derived from QKeySequence and QShortcutMap) seems very large... and not completely necessary for KDE purposes. If I understand correctly, the Scheme of QKeySequence <-> QMouseShortcutMap <-> QShortcutEvent, invoking QActions, is required ONLY because Keyboard does not have "automatic" focus management. But with the Mouse, MouseArea elements and QWidgets which are "visible" have focus automatically, and events which were not
accepted get "pushed back" onto their parents/background elements automatically.

If so, then I think that we do not need to have "mouse shortcut" class within Qt. Instead, can we just create "Human Interface Guideleines" (HIG) for mouse within KDE, and advise programmers NOT to use those "shorcuts" incorrectly? And for the case of "Global shortcuts", can we possibly provide skeleton code, or an entire Object, which serves as an eventFilter() for pointer events at the KApplication level?

Although I solved bug 43692, I am not a C++ programmer, and would need guidance in working on this myself. I would also be VERY slow to create code. So, I would prefer to contribute by working on the HIG.

In Qt5 , we have a largeer number of "mouse buttons" on most platforms. (16 on
OS-X; 16 or 31 Linux according to your choice of Driver; and 10-16 on
tablet devices). But we will also have a full-width button State mask:
The event /mousebuttons/ mask values are supposed to indicate "Pressed
State" for ALL of the buttons which you have pressed, even when graphics
platform (Wayland, XCB, Cocoa, QNX) provides only a small mask to us.

(In Qt 4.8 and earlier, you can only see "held" State for LeftButton, RightButton, and MiddleButton).
Comment 44 Rick Stockton 2012-12-27 06:42:54 UTC
I would suggest the following options in a KCM GUI for on-the-fly change of "mouse shortcuts":

We should perhaps give the User a "test click" area, in which they may click a button on their pointer device end see it's ID displayed. (If so, this should be a copy/paste string.)
"EVENT BUTTON" = the button which is clicked or doubleclicked (required).
"HELD BUTTONS" = "wwww + xxxxx + yyyyy +zzzzz + ...." (user should type in a
string of Qt::MouseButtons, we should NOT try to guess when they "might"
be finished).
"HELD MODIFIERS" = Ctrl + Shift + Super + Alt + Mod5 .... (Any
combination; perhaps the current "click in the digram" is a good GUI for
this.)

We probably want to limit mouse shortcuts to being either 'Release' or 'DblClick', because we have no way to tell if a Button 'Press' is meant as an event... or is merely getting ready to be used as a 'held button'.

And, we should not limit users according to the limits of their current mouse device. Some people have only 3 buttons on airplanes, but have 7 or 10 buttons at home :))
Comment 45 Thomas Lübking 2014-01-05 20:06:04 UTC
*** Bug 329634 has been marked as a duplicate of this bug. ***
Comment 46 Michael 2015-09-30 18:11:10 UTC
I would love to see this working in the future!
Comment 47 Montblanc 2015-11-11 20:43:45 UTC
I used Super + Mouse Wheel on Compiz (Beryl) back in 2006 and it still is not available in Kwin after almost 10 years. I think it's the most convenient, fast and intuitive shortcut to zoom in and out, will it be added anytime soon?
Comment 48 Martin Flöser 2015-11-12 06:53:48 UTC
> and it still is not available in Kwin after almost 10 years

of course it's available, but only on Wayland and because of that not configurable.
Comment 49 Thomas Capricelli 2016-07-21 15:54:08 UTC
Why "of course" ? Is that this obvious ... ?
Comment 50 mm0.gamer1 2016-08-17 02:20:41 UTC
I'd love to see this feature implemented in kde.
Comment 51 Luigi Baldoni 2016-08-17 06:54:58 UTC
I'm afraid the only way is to use xbindkeys or switch to wayland.
Comment 52 Matt Whitlock 2016-08-17 08:41:26 UTC
(In reply to Aloysius from comment #51)
> I'm afraid the only way is to use xbindkeys or switch to wayland.

Preposterous. If xbindkeys can do it, then KDE's global hotkeys daemon can do the same thing. It's as simple as grabbing all the buttons that have shortcuts assigned to them, isn't it?
Comment 53 Martin 2017-09-27 19:59:08 UTC
*** Bug 384265 has been marked as a duplicate of this bug. ***
Comment 54 Martin Flöser 2018-03-18 14:26:17 UTC
On X11 this cannot be implemented. And on Wayland we do have support for mouse button shortcuts for a limited set of actions in KWin. The number of possible and useful mouse shortcuts is rather low and thus no ui is available just like for modifier only shortcuts.

Anyway setting to won't fix as we won't implement support for this on X11 anymore even if we could. I am sorry that the bug has been open for so long although it is obvious that our infrastructure doesn't allow for mouse button shortcuts.
Comment 55 Nate Graham 2018-03-18 14:30:51 UTC
Martin, this bug has a lot of history behind it that I would hate to see get lost. Can we keep it open and use it to track improving the Wayland support?
Comment 56 Thomas Capricelli 2018-03-18 14:33:53 UTC
No offense, but I don't undersand the "it's not possible in X11".  Openbox supports it, and i dont think they do any kind of black magic here.

kwin not supporting this is the only reason preventing me to use it in an otherwise full plasma-kde-desktop env. I'm using two additionnal buttons on my mouse for moving and resizing, clicking anywhere on the window (and not only on borders/corners). It helps tremendously. It looks like this in openbox config file : 

      <mousebind button="button8" action="Drag">
        <action name="Resize"/>
      </mousebind>
      <mousebind button="button9" action="Drag">
        <action name="Move"/>
      </mousebind>
Comment 57 Nate Graham 2018-03-18 14:36:17 UTC
Let's not get into the weeds regarding support on X11. X11 is feature-frozen at this point, so it's moot, I'm afraid. Let's focus on the Wayland use cases instead; that's our path forward.
Comment 58 Luigi Baldoni 2018-03-18 17:37:09 UTC
Ok, what about Wayland then?

Having mousewheel support would be neat.
Comment 59 JimiJames.Bove 2018-03-18 17:56:40 UTC
Personally, I'm genuinely curious about how Openbox implements this vs. what limitation in X11 makes it not viable for KDE/Plasma.
Comment 60 Thomas Capricelli 2018-03-18 19:10:32 UTC
(In reply to JimiJames.Bove from comment #59)
> Personally, I'm genuinely curious about how Openbox implements this vs. what
> limitation in X11 makes it not viable for KDE/Plasma.

Yes, as a code, i'm curious to know as well ! ;)
Comment 61 Martin Flöser 2018-03-18 19:51:44 UTC
@Nate: I suggest to use a new bug report or better maniphest task for Wayland. It's a different issue now. We have the support just need to improve it. I'm not a fan of meta bugs. A few dedicated maniphest tasks are much better to handle. My suggestion would be to reset this bug to wontfix. I leave that decision to you.

For those asking questions regarding X11: this bug has been open now for 13 years. I implemented this functionality on Wayland years ago. I backported many Wayland improvements to X11. I hope you trust me if I say that our architecture doesn't allow to implement it on X11. At that point it's also irrelevant whether other environments found a solution. Our architecture doesn't support it.
Comment 62 Luigi Baldoni 2018-05-03 20:05:15 UTC
Is it conceivable to use something like xbindkeys, but compatible with wayland, as temporary solution?
Comment 63 Carlo 2022-09-01 13:58:45 UTC
I have no idea if this is still taken into consideration, but I'm also interested in this being implemented. Even more so now that Wayland is here.
Wayland no longer allows applications to grab inputs by applications. The peak example is VoiP programs that support push-to-talk.
Some apps (see Mumble) are starting to adapt by exposing an rpc interface (e.g., `mumble rpc starttalking` and `mumble rpc stoptalking`). That's a great start, but not being able to bind those commands to a mouse button makes them quite useless.

Additionally: i don't know if it's possible but it would be interesting to have an option to execute a different command on press & release of the same button.
Comment 64 Jakob 2023-06-03 09:56:46 UTC
Now with the XDG global shortcut portal API, this became way more relevant. Hotkeys like push to talk, toggle to mute and such registered by applications (for example mumble with https://github.com/mumble-voip/mumble/pull/5976 this patch) are very useful when bound to mouse buttons which is currently not possible without workarounds (like configuring my mouse to send keyboard keycodes for those buttons).
Comment 65 Andrew Shark 2023-08-06 22:39:24 UTC
This bug is very much outdated and unmaintained. No much useful info in the comments.
The KHotkeys is no longer maintained. The bug description (what exactly is needed to be fixed) is vague. Please see another bug reports for the exact features needed (push to talk, mouse buttons in shortcuts).