The UI is trying to hide a bit of complexity from you. The way it works under the hood is as follows:

With the Libinput library's "Clickfinger" click mode, you right-click by pressing down on the pad with two fingers (or three fingers, of one of the fingers is a thumb at the bottom of the pad), and you middle-click  pressing down on the pad with three fingers (or four fingers, of one of the fingers is a thumb at the bottom of the pad).

With the Libinput library's "Areas" click mode, you right-click by pressing down with your thumb on the bottom-right corner of the pad, and you middle-click by pressing down with your thumb on the bottom-middle of the pad, which a lot of people find confusing and want to turn off.

To turn it off, you use "Clickfinger" mode. We don't have another way to turn it off because this behavior comes from the Libinput library itself and it doesn't give us a knob to turn to affect it without changing the click method setting.

The UI in this page hides all of that from you because nobody would want to read the essay explaining it. :)

(In reply to Nate Graham from comment #1)
> The UI is trying to hide a bit of complexity from you. The way it works
> under the hood is as follows:
...
> The UI in this page hides all of that from you because nobody would want to
> read the essay explaining it. :)

Thanks for the detailed explanation, Nate.  The part that bothers me is that the UI calls this "Right-click" settings and makes absolutely no reference to this affecting "middle-click".  So when I searched for settings regarding "middle-click", this didn't turn up.  And when I read the text for this setting, it didn't seem to apply to my situation.

I think my summary made my concern less clear in my original report.  Let me clarify.  The problem I am reporting here is:

     "Right-click" setting SECRETLY affects middle-click.

That is, there is no suggestion to the User that this setting affects middle clicks at all.  

I appreciate that UX is hard and that it would be terrible to change this setting to "Enable Libinput areas mode", for example.  I am suggesting it needs something in-between these extremes. 

Here's a suggestion:

> Middle-click and Right-click settings:
>       ( ) press bottom-middle edge / bottom-right corner
>       ( ) press anywhere with three fingers (middle) or two fingers (right)

But I don't like that much, either. I was hoping a KDE UX dev might have some better ideas.

Another option:

> Right-click settings:
>       ( ) press bottom-right corner for right click (bottom-center for middle click)
>       ( ) press anywhere with two fingers (for middle click use three fingers)

Even a hover-tip with some elucidation would be nice, or a small info box near the setting that changes to describe the setting whenever it is changed.

Created attachment 156967 [details]
Mockup for proposed new design

Here's a crude low-fi mockup showing an idea I have to make this UI clearer. What do you think?

(In reply to Nate Graham from comment #3)
> Here's a crude low-fi mockup showing an idea I have to make this UI clearer.
> What do you think?

Wow, that is a lot more elaborate than I was expecting or thought was viable.   I like the direction and I think it would help.  But it does bring a lot of extra details to digest.

Two surprising things to me in this mockup:
1. There's an option to control whether middle-click exists in the "Areas" mode.  That would be nice to expose
2. There's a thumb-rest area in the "Fingers" mode.  That info seems a little distracting, but also important if someone gets confused because two-finger-click resulted in a LeftClick because one of their fingers was too near the bottom edge.  

Question: would the "Middle click by pressing left and right together" work only if the same option was enabled for the physical buttons?

Another way to say this with simple text could be like this:
> ( o )  Press bottom-right corner for right-click
>         [ x ]  Press bottom-center for Middle-click
> 
> (   ) Press anywhere with two fingers for right click, or three fingers for middle click

Egads! I just noticed the "Tapping" options allow two- and three-finger actions to be swapped.  Is that only for tap modes?

(In reply to Phil Hord from comment #4)
> 1. There's an option to control whether middle-click exists in the "Areas"
> mode.  That would be nice to expose
It is exposed in that mockup; that's what the radio buttons for middle-clicking while using areas mode control. The "pressing left and right together" option makes the virtual middle-click button disappear.

> Question: would the "Middle click by pressing left and right together" work
> only if the same option was enabled for the physical buttons?
When the touchpad has physical buttons we woudn't show this UI at all; it's only relevant to buttonless touchpads.

> Another way to say this with simple text could be like this:
> > ( o )  Press bottom-right corner for right-click
> >         [ x ]  Press bottom-center for Middle-click
> > 
> > (   ) Press anywhere with two fingers for right click, or three fingers for middle click
It might work, but the issue with that checkbox is that its opposite state becomes unclear. If I uncheck it, how do I middle-click when using the first radio button? The UI doesn't say.

> Egads! I just noticed the "Tapping" options allow two- and three-finger
> actions to be swapped.  Is that only for tap modes?
Yeah.

Created attachment 171823 [details]
Touchpad UI mockup

@Nate  I think a graphic for this menu like you've demonstrated is an absolute necessity. I really like the idea behind the mockup. 

((( Please look at the attachment before reading this wall of text )))

It also needs to take all the wacky touchpad customizations into account, of which full extent I am not aware of that libinput can do. 
Gestures should also be considered, even though they're not implemented yet, so planning with infinitely buttons than the three main mice one would come in handy later.

Currently, one can have such a cursed setup where I can tap to click for RMB/LMB, tap bottom right corner disabled, press anywhere for LBM, press bottom right for RMB (notice missing tap to click RMB in the bottom corner, which I have reported here as I am unsure if that's intended or breaking, I say breaking https://bugs.kde.org/show_bug.cgi?id=490546).

I would only have one dynamic graphic view + dynamic text for LBM, RMB, and MMB that shows the current state, in the likeness of what you have done. 

I took your older mockup, have done away the idea of presets and reduced the amount of checkboxes by moving them to a gestures menu (which is now there).

I have also added a device selector, for when people connect multiple touchpads.

I expect the 'current state' graphic to be dynamic like:

<Current state>
[graphic showing the areas, maybe highlight the section on hover if feeling fancy]

Left mouse button:
  * [Press||Tap||Press or tap] anywhere

Right mouse button:
  * [Press||Tap||Press or tap] anywhere
  * Gesture: 2-finger tap

Middle mouse button:
  * Gesture: 3-finger tap

<Gestures table allowing for infinite definitions of random keys like>
Gesture bop it:
  Back button
 
Gesture: smash it
  Forwards button

I'm pleased with the current changes that added text explaining that middle-click is also affected by these settings.  

It's still a little confusing for the uninitiated, and maybe there's more redesign to be discussed here.  But I'll mark this resolved as the middle-click behavior is no longer surprising (and "secret").  

Reopen if you want to continue refactoring.