Bug 441717

*Extremely* bad usability not to have the only pointing device available, a buttonless touchpad in my case, not enabled with tap-to-click by default.

Twice now, while testing whether a bug exists with a clean/blank user config (empty home dir), I've ended up without a working pointer and had to keyboard-navigate to the touchpad kcm, then tab/arrow/space/enter/alt-A-apply to enable the touchpad and tap-to-click, after which I have at least /basic/ pointer functionality to do the rest of basic config before I can test whatever bug I was testing.

I can only imagine that a normal new-to-plasma user would simply assume it's all broken and without a working pointer or knowledge of how to get out of plasma without one, may have to actually restart the computer and never *ever* try *that* again, meaning never trying plasma again, in ordered to avoid the breakage!

(Meanwhile, I'm confirming the bug, and given the invitation, moving it to systemsettings.  After that I'll try to switch the component to touchpad, but it's still giving me neon comonents and not switching to systemsettings components, until I save the systemsettings change.)

(Successfully changed the component, and since I'm on live-git where it still occurs, set master.  Also adding usability flag.  With any luck that'll help get it the needed attention.)

Not something we can do in KDE as this is a default setting of the Libinput driver. It's up to distros to override it, not us.

Speaking personally, I don't like tap-to-click at all and much prefer physically clicking. I know the developer of the Libinput driver feels similarly. So it's not a universally-agreed-upon thing that tap-to-click is better. :)

If it's a distro thing that means Neon was correct after all, as that's the kde-level distro.

And it's still *extremely* bad usability to have the only available pointing device, a buttonless touchpad, now we know *deliberately* left broken.

(In reply to Nate Graham from comment #3)
> Speaking personally, I don't like tap-to-click at all and much prefer
> physically clicking.

Arguably true when there's a device with a physical clicker.  But there's not, when the only available pointing device has no physical buttons.

> I know the developer of the Libinput driver feels
> similarly. So it's not a universally-agreed-upon thing that tap-to-click is
> better. :)

In what way is disabling clicking on the only pointing device available better than having it actually work?  If people don't like it and it's on, it's easy enough to turn off.

But if people are left with an unclickable pointing device because the only one available is disable by default, it's horribly difficult to turn on, all but impossible if you don't already know where to navigate and you're left to trial-and-error -- without a working clicker!

(In reply to Duncan from comment #5)
> In what way is disabling clicking on the only pointing device available
> better than having it actually work?  If people don't like it and it's on,
> it's easy enough to turn off.
> 
> But if people are left with an unclickable pointing device because the only
> one available is disable by default, it's horribly difficult to turn on, all
> but impossible if you don't already know where to navigate and you're left
> to trial-and-error -- without a working clicker!
I think you may be confused. For buttonless touchpads, you generally press down on the pad to click. There will be an audible button press sound, because the whole touchpad is one big button. You don't have to tap to click.

If press-to-click doesn't work with your buttonless touchpad, it is quite broken.

(In reply to Nate Graham from comment #6)
> I think you may be confused. For buttonless touchpads, you generally press
> down on the pad to click. There will be an audible button press sound,
> because the whole touchpad is one big button. You don't have to tap to click.
> 
> If press-to-click doesn't work with your buttonless touchpad, it is quite
> broken.

Logitech t650 wireless rechargeable touchpad.  It was introduced when Windows 8 gesture support was the new big thing (Wikipedia says in 2012) and is long discontinued tho it's still available from private resellers at jacked up prices ($300 new, $100 used, IIRC I paid ~$50 new back then, but it's still in demand with some due to its relative robustness and "natural pointing" usage pattern that can help reduce repetitive motion disorder) from Amazon.  The face is just a bare pad, tho it did have one physical button, designed to be the context-click aka right-click button, as the bottom-right foot-pad.  But it was /designed/ with tap-to-click for the primary button and (without remapping the bottom-right-foot-button secondary-to-primary) has no other alternative for that.  (And FWIW, the foot-button is now long gone as well, but two-finger-tap was always easier for me anyway so that never bothered me.)

https://en.wikipedia.org/wiki/List_of_Logitech_products#Touchpads

https://www.amazon.com/LOG910003057-Logitech-Wireless-Rechargeable-Touchpad/dp/B0093H4WT6

So it may well be "quite broken" by your definition, but it works and has helped keep repetitive-motion-disorder at bay for me, and it needs tap-to-click because there never was a physical primary button at all and the physical secondary's long gone.

Now personally it'd be easier for me (as a gentooer building my own packages anyway, just drop the patch in the appropriate auto-apply dir) to find and hack-patch the boolean default, but we already know there's at least the original bug filer who needed the functionality as well, and surely there are others.  I think it's worth it, particularly when it could be as easy as a default value flip (tho a bit harder if logic to enable it only when a touchpad is the only available pointing device is added), and the penalty for getting it wrong is a practically unusable system due to lack of ability to click.

What an interesting piece of hardware. I would recommend that you submit an issue report to Libinput (the touchpad driver project) at https://gitlab.freedesktop.org/libinput/libinput/-/issues/ asking for tap-to-click to be enabled by default automatically for this device. This strikes me as reasonable because the hardware was designed to be used in that way.

Neon Devs said no in https://bugs.kde.org/show_bug.cgi?id=436077#c6. Read there for the explanation.

I request the same (I did not see this bug report): https://bugs.kde.org/show_bug.cgi?id=451872

For me, the actual setting is a bad design decision. In fact, I consider it a 15-minute bug from user expectation.

Regards.

See Bug 429665.