Part-time KDE sabbatical, feedback or guidance appreciated (but no pressure)

Jakob Petsovits jpetso at
Mon May 8 04:25:09 BST 2023

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

More information about the kde-devel mailing list