For inspiration: I think Piper handles the key mapping pretty:

In T12831#223710, @alexde wrote:

For inspiration: I think Piper handles the key mapping pretty:

Piper's requirements and our requirements are kind of different. We just want a simple, flexible mouse button remapping. Piper even requires specific definitions of the devices : https://github.com/libratbag/libratbag/tree/master/data/devices

What do you think about this issue ?

Here's what I'm imagining:

• On the main page of the Mouse KCM you have a button with a label like "Customize button mapping" or "Remap buttons".
• That button takes you to the button remapping page.
  • On the remapping page, you have a list on the left to select the device if there are multiple devices.
  • On the right side, you have a table of buttons and mappings.
    • In the first column, you have all the buttons provided by the selected device, preferrably with common names. Maybe plain button IDs in parentheses.
      • If there really is no way to do common names, then I guess we'll just have IDs.
    • In the 2nd column, you have what that button is mapped to.

Having it on a separate page allows us to focus on making an optimal layout for customizing buttons and it keeps the confusing clutter out of the main page.

Hello, I think the text "Device" after the device name is too English-specific. It would be tougher to translate to many left-to-right languages since most do possess a structure like "Device: DeviceName" but not many have the "DeviceName Device" inversion.
The solution I see would be a heading, which is unfitting to how the KCM currently looks, but this is solved by having a separate page like Noah mentioned.

I have another idea that is possibly less flexible than a plain table of IDs and mappings, but more intuitive.

Instead of a plain table of IDs and corresponding mappings, have a table of bindings. It's similar in that it will still show button IDs in the 1st column and mappings in the second column, but it won't be a dump of all buttons with no clue as to what IDs match what mouse buttons.

• Have a button to add a binding to the table.
• Have inline button controls to remove bindings.

When a user adds a binding:

• The user will be prompted to press the button on their mouse that they want to rebind.
• The user will be prompted to select what they want to bind the button to.

This way users don't need as much trial and error to get the correct binding.

If we do go with the idea above, it might be a good idea to allow bindings to edited without requiring users to remove the binding first.

Thanks for the comments.

@ndavis That button takes you to the button remapping page.

We should prevent from new windows. There maybe a tabbed view instead but is it really a good idea while trying to remove tabs from other KCMs ? Tabbed design may be the last solution imho.

@thiagosueto I think the text "Device" after the device name is too English-specific.

They are not combined actually. Right label defines the left side, it is not be read like "Logitech M704 Device". It is like "ComboBox | Left side shows the device". As you said, it doesn't really fit to Kirigami design.

From your feedbacks, I did something like that:

What do you think ?

In terms of the UI, we're trying to move away from tabs and towards multi-page KCMs where clicking on a button takes you to another page. For examples, see the Notifications and Style KCMs.

But maybe we should step back: what are the typical use cases for button re-mapping? Libinput already transparently supports one: reversing the position of the right button, for left-handed users. @furkantokac has listed another one: making some other button behave like a middle button.

However this seems pretty limited compared to what I think most users would expect today: the ability to assign custom actions and commands to the additional buttons of especially button-filled mice, some of which have 7 or more buttons. This would of course include making buttons behave like other buttons, but doing *only* that seems like it would generally be of fairly limited use all on its own.

In terms of the UI, we're trying to move away from tabs and towards multi-page KCMs where clicking on a button takes you to another page. For examples, see the Notifications and Style KCMs.

We discussed the issue yesterday on IRC. I'm gonna share new mockup soon.

However this seems pretty limited compared to what I think most users would expect today: the ability to assign custom actions and commands to the additional buttons of especially button-filled mice, some of which have 7 or more buttons. This would of course include making buttons behave like other buttons, but doing *only* that seems like it would generally be of fairly limited use all on its own.

This is an another topic. I just have time to imlement remapping. Its functionality can be extended later, step-by-step.

All right, fair enough!

Hello, with this, would it be possible to assign ScrollMethod and ScrollButton?
Currently, mice such as the Trackman Marble, which I use, require a xorg conf file in order to allow scrolling with the trackball, both for xinput and libinput.
On Wayland it even requires a dbus command in order to activate this functionality, as mentioned by former KWin dev Martin.