Bug 394529 - Configure Mouse buttons (Global Shortcuts should accept accept mouse clicks to trigger actions/keypresses/scripts)
Summary: Configure Mouse buttons (Global Shortcuts should accept accept mouse clicks t...
Status: RESOLVED INTENTIONAL
Alias: None
Product: kwin
Classification: Plasma
Component: input (show other bugs)
Version: unspecified
Platform: Other Linux
: NOR wishlist (vote)
Target Milestone: ---
Assignee: KWin default assignee
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-05-21 17:18 UTC by sac
Modified: 2022-04-18 07:55 UTC (History)
5 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 sac 2018-05-21 17:18:52 UTC
Hi,

would be great to have an option to customize the mouse buttons. 

There was once btnx or easystroke tools to some customization and there's alot of documentation regarding the usage of the mouse wheel button as doubleclick ( https://help.ubuntu.com/community/MouseCustomizations ). However, even with the shortcut setting it all comes to generate scripts and using additional programs & services in the background all the time, like xbindkeys (that won't work in wayland).

It would be great to have some options here. Settings>Shortcuts offers some limited customizability. My Logitech Master MX thumb button is recognized as CTRL+ALT+TAB and I can assign it to "close window", however, I cannot use the same the same shortcut then to close a tab in FF (because it's already assigned to "close window"). An option to assign an action / click / keypress to a mouse button would be great, maybe even specific for some applications.
Comment 1 Christoph Feck 2018-06-15 01:19:26 UTC
Input remapping would need to be implemented in KWin for Wayland.
Comment 2 Roman Gilg 2018-06-15 10:05:52 UTC
There has been a GSoC project last year writing a GTK based ui for configuring gaming mice in libinput. Don't know if it got merged into GNOME or what's the current state is:

https://www.hjdskes.nl/blog/gsoc-part-15/

Might be worth a look for inspiration at least.
Comment 3 Martin Flöser 2018-06-15 12:52:21 UTC
Conceptionally this is wrong in KWin. Kglobalaccel should learn about mouse shortcuts instead.
Comment 4 Christoph Feck 2018-06-15 17:37:45 UTC
You mean KHotkeys? KGlobalAccel doesn't emit fake input events to applications, as far as I know.
Comment 5 Martin Flöser 2018-06-15 19:19:24 UTC
(In reply to Christoph Feck from comment #4)
> You mean KHotkeys? KGlobalAccel doesn't emit fake input events to
> applications, as far as I know.

On Wayland we will never emit fake input events. The only possible things are global shortcuts going over dbus and that's exactly what kglobalaccel does.
Comment 6 Christoph Feck 2018-06-15 19:58:42 UTC
That does not help applications expecting a mouse click. If I understand you correctly, KDE cannot offer central customization; it has to be handled by each application individually.
Comment 7 sac 2018-06-16 12:20:47 UTC
So, to what should I reassign this? Or should I open a new bug to change the KGlobalAccel API, or systems settings can already make use of the API for mice as well?
Comment 8 Christoph Feck 2018-06-16 12:48:58 UTC
Changing KGlobalAccel won't help, it cannot generate mouse clicks, it only sends D-Bus messages to applications when you press the global shortcuts. Those D-Bus messages are then translated to QAction triggers. As I said, it won't help for applications that need QMouseEvent.

If libinput doesn't allow plugins to generate fake input events (or remapping input events), then either the Qt toolkit would need to be expanded (very unlikely to happen, because Qt developers stay away from any type of configuration), or the applications need to handle it.
Comment 9 sac 2018-06-17 00:34:29 UTC
Understood, there's no maintainer for libinput configs ( http://who-t.blogspot.com/2016/04/why-libinput-doesnt-have-lot-of-config.html ) and button remapping is still a big showstopper for default wayland on KDE.

However, seems that there's already a deamon available https://github.com/philipl/evdevremapkeys

Any plans to utilize sth. like this to offer some customization options in the settings?
Comment 10 Martin Flöser 2018-06-17 06:22:17 UTC
(In reply to sac from comment #9)
> Understood, there's no maintainer for libinput configs (
> http://who-t.blogspot.com/2016/04/why-libinput-doesnt-have-lot-of-config.
> html ) and button remapping is still a big showstopper for default wayland
> on KDE.
> 
> However, seems that there's already a deamon available
> https://github.com/philipl/evdevremapkeys
> 
> Any plans to utilize sth. like this to offer some customization options in
> the settings?

You can use this, but we won't add anything which utilizes this or encourages to use it. This is a huge security risk and thus is unsuited for a secure Wayland session. One of the biggest security issues of X is the possibility to generate fake input events.
Comment 11 sac 2018-06-23 23:52:30 UTC
OK, we need a proper solution. 

Apart from security, evdevremapkeys & xbindkeys don't work for productive use (GTK apps like Thunderbird remap input events, one has to click several times to trigger an action after another window had focus; totally messed up).

Libinput pointed back to DE & Toolkit ( https://gitlab.freedesktop.org/libinput/libinput/issues/44 ).

This affects basically every user and we expect from them to reprogram Kernels if they want to remap sth. properly :( Does noone have good connections to QT, which I guess is our last option here?
Comment 12 Martin Flöser 2018-06-24 06:14:10 UTC
I think this is overall a wish which is just too complex. Peter's answer in the libinput request is really good. You need to change all toolkits and all compositors to support this. But changing the toolkits won't be sufficient. Even the toolkit doesn't have enough information. For a browser it is obvious where a close tab action should go to. But what to do if you have Kate in split screen with multiple tabs and maybe a Konsole window with tabs. Then you have three tab bars, where should the action go? No toolkit will be able to answer such a question. The toolkit developers will notice such issues and thus not add a general solution.

And then we are back to interact with each application. As I said in my first reply: global shortcut triggering is pretty much the only possibility I can think of.
Comment 13 sac 2018-06-24 16:14:36 UTC
>As I said in my first reply: global shortcut triggering is pretty much the only possibility I can think of.

Got you now & renamed the bug. That solution would be perfect. @Christoph Feck GS wouldn't have to genereate mouse clicks in that case. It would just have to learn to accept those as input / trigger. In addition, the option to assign a shortcut to several actions would be great.

(Maybe libinput can later cover at least the mousewheel as doubleclick case, that would help in 90% of the cases).
Comment 14 Christoph Feck 2018-06-25 00:58:16 UTC
Why are you reopening this ticket? How would a global shortcut help an application that expects mouse events to open a context menu or execute a double-click action? Global shortcuts already work, and you would have to change the application to either handle those shortcut events, or you would have to change the Qt toolkit to transform those into mouse events.

This will not be fixed in KWin, according to its developers.
Comment 15 sac 2018-06-30 19:29:07 UTC
>Why are you reopening this ticket? How would a global shortcut help an application that expects mouse events
>This will not be fixed in KWin, according to its developers.

I think you're not getting the idea here. Forget about mouse events (no mouse events in this bug report). The suggestion of the developers was to adjust global shortcuts.

Currently Global Shortcuts shows the following tooltip:
"Click on the button, then enter the shortcut like you would in the program. 
Example for CTRL+A: hold the CTRL key and press A."

Instead the tooltip should say:
"Click on the button, then enter the shortcut like you would in the program on your keyboard or mouse. 
Example for CTRL+A: hold the CTRL key and press A.
Example for righ mouse button: press the right mouse button.
"

In addition, the option to assign a shortcut to several actions would be great.

(yes, I know, just changing a tooltip is only 5% of the work, but maybe this explains it better. BTW: there are keyboards with a button for a mouse context menu. So even a mouse context menu can be triggered, if there's an action for this KEYBOARD BUTTON. Again: no mouse events here, but I'm able to customize my mouse and am even able to call batch sripts or programs [that might trigger mouse events, ugh forget that])
Comment 16 Martin Flöser 2018-07-01 05:28:11 UTC
Let's set it back to wontfix as that is the correct state from KWin perspective. Moving this feature request to kglobalaccel doesn't make sense as there is too much unrelated discussion in it.
Comment 17 tomashnyk 2022-01-10 15:50:31 UTC
For people coming here through google, the proper bug seems to be this: https://bugs.kde.org/show_bug.cgi?id=171295