Bug 96431

*** Bug 109374 has been marked as a duplicate of this bug. ***

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.

*** This bug has been marked as a duplicate of 48062 ***

This is not a duplicate, bug #48062 asks for mouse buttons to act as modifiers.

*** Bug 98778 has been marked as a duplicate of this bug. ***

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.

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

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.

*** Bug 171295 has been marked as a duplicate of this bug. ***

*** Bug 176392 has been marked as a duplicate of this bug. ***

*** Bug 156082 has been marked as a duplicate of this bug. ***

*** Bug 168771 has been marked as a duplicate of this bug. ***

*** Bug 178633 has been marked as a duplicate of this bug. ***

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.

any news on this one?

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.

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.

Something new on this issue ? Last comment is from february.
I'd really like to have meta+scrollwheel zoom.

(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 ;-)

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

(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

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?

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.

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.

(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.

There should be some kind of database with local shourtcuts to check conflicts when setting global ones.

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.

Anything new on that? For me it would be enough if Dolphin would support mouse buttons to navigate forward or back...

Yay, This would a pritty nice feature :/.
I have the same Problem.

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.

Would be really nice to have it.

"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?

The enhancement/fix has already been submitted to Qt.

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.

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.

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.

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!

*** Bug 276413 has been marked as a duplicate of this bug. ***

*** Bug 193349 has been marked as a duplicate of this bug. ***

*** Bug 226370 has been marked as a duplicate of this bug. ***

(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)

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.

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).

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 :))

*** Bug 329634 has been marked as a duplicate of this bug. ***

I would love to see this working in the future!

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?

> 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.

Why "of course" ? Is that this obvious ... ?

I'd love to see this feature implemented in kde.

I'm afraid the only way is to use xbindkeys or switch to wayland.

(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?

*** Bug 384265 has been marked as a duplicate of this bug. ***

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.

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?

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>

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.

Ok, what about Wayland then?

Having mousewheel support would be neat.

Personally, I'm genuinely curious about how Openbox implements this vs. what limitation in X11 makes it not viable for KDE/Plasma.

(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 ! ;)

@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.

Is it conceivable to use something like xbindkeys, but compatible with wayland, as temporary solution?

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.

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).

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).