On Sun, May 7, 2023, at 10:11 PM, Joshua Goins wrote: >> I'd also be interested in having something like the mouse button mapping UIs >> that Windows users get from their mouse manufacturer, enabling remapping of >> mouse buttons not just to keys but also to modify other mouse (or keyboard) >> behaviors while pressed. With Wayland it can be app-/window-specific too, I >> think. And of course it would be a good selling point that hey, *any* mouse >> can have all the features as opposed to being tied to the driver and >> manufacturer. Some changes to KWin will likely be required to power the >> configured mapping in practice. Ultimately this kind of configuration UI >> should be part of in System Settings. > > This already exists in some capacity - you can remap extra mouse buttons in > the Mouse KCM (the button is called "Re-bind Additional Mouse Buttons..."). > Not sure how well it works, because it doesn't pick up on my additional > buttons on my G600 for some reason. The help is always appreciated though, > especially for modifier support and such which I think is a limitation of our > current system.
Thanks for the warm welcome, and the reminder! I was aware of this (hence the "not just to keys" quote) and I definitely still have to check out the code to get a better sense of it. It's interesting to consider the contrast between button/key mappings and action mappings. The latter is necessarily app-specific and that's pretty great, at least for KDE apps that allow setting shortcuts with KDE settings dialogs / System Settings. Interactions such as Ctrl + left-click in an image/vector editing app are more similar to actions, but are also somewhat different in that they're highly context-dependent (on the mouse pointer position) and there won't be a shortcut action exposed for it. Needs a different way to configure the mapping. Still conceptually app-specific though, or even "context"-specific e.g. to the app's canvas view. Non-KDE apps and games probably need to map the button press to another simulated peripheral input. This could work in a way that's similar to KWin's window rules, although for games (i.e. an exclusively full-screen app) it would be even nicer to have a screen overlay à la Steam Deck's game-specific controller mapping settings. Too far removed for a starter project, but does make me wonder if slide-in settings overlays for compositor/input functionality are useful in other circumstances (apps in Plasma Bigscreen maybe?) as well. Anyway, let's not get ahead of myself. Going to look at bug reports first. Cheers! - Jakob
