<html> <head> <base href="https://bugs.freedesktop.org/"> </head> <body><a class="email" href="mailto:peter.hutterer@who-t.net" title="Peter Hutterer <peter.hutterer@who-t.net>"> Peter Hutterer</a> changed <a class="bz_bug_link bz_status_ASSIGNED " title="ASSIGNED - Button areas on Lenovo Thinkpad W540" href="https://bugs.freedesktop.org/show_bug.cgi?id=99212">bug 99212</a> <table border="1" cellspacing="0" cellpadding="8"> <tr> <th>What</th> <th>Removed</th> <th>Added</th> </tr> <tr> <td style="text-align:right;">Status</td> <td>NEEDINFO </td> <td>ASSIGNED </td> </tr></table> <div> <a class="bz_bug_link bz_status_ASSIGNED " title="ASSIGNED - Button areas on Lenovo Thinkpad W540" href="https://bugs.freedesktop.org/show_bug.cgi?id=99212#c9">Comment # 9</a> on <a class="bz_bug_link bz_status_ASSIGNED " title="ASSIGNED - Button areas on Lenovo Thinkpad W540" href="https://bugs.freedesktop.org/show_bug.cgi?id=99212">bug 99212</a> from <a class="email" href="mailto:peter.hutterer@who-t.net" title="Peter Hutterer <peter.hutterer@who-t.net>"> Peter Hutterer</a> <pre>(In reply to Markus Schmidt from <a href="show_bug.cgi?id=99212#c8">comment #8</a>) > From my understanding as UX/UI dev both (extreme) ways is a can of worms: [...] yeah, I agree. Right now, I quick grep counts 16 different options already, not counting the ones we adjust based on the device (i.e. where the device has specific behaviour because it wouldn't fit the standard behaviour but we don't expose a config for that). > What about a helpful, easy-to-use, restriction-aware _graphical_ user > interface for configuring libinput? I don't mean a couple of meaningless > faders or numerical values but something like I did with e.g. xplanetFX ( > <a href="https://youtu.be/x9SyYLu_M6M">https://youtu.be/x9SyYLu_M6M</a> ) or WifiRadar ( <a href="http://bit.ly/2irXgvY">http://bit.ly/2irXgvY</a> ) both of those are end-user applications. libinput is a library used by the compositor and users don't have direct access to it. having a GUI to libinput would be akin to having a GUI for glibc - it just doesn't make sense this way. the GUI for libinput is the gnome control panel, or the KDE settings panel, or ... The problem is: unless you go full "yes to anything", you always have some limit of where you draw the line in further configuration options. And each option increases the required test scenarios (and guess who has to write those tests :) but right now we're just arguing about where the line is drawn and that's just a subjective argument, as maintainer I just have to say no to a lot of people ("yes is forever...") > * pro users with the need of having a custom configuration could easily > tweak some of the most demanded values via a (restricted) GUI without the > jeopardy of making their input devices unusable (preventing from lots of > support requests) and > * hardcore users would still be able to fuck up their systems intendedly by > tweaking a text file problem is: you can't separate things this way with libinput, as said above the configuration is controlled by the compositor (or the xorg driver) > So I would like to finish with a possibly controversial statement - what I > love *most* on Linux is the fact that normally everything is tweak-able to > the users needs. You don't like something? Open a terminal and change the > configuration. I really don't understand e.g. the Gnome3 way - strip off > every single button/menu entry/config to force the user to use the software > *their* way. I love to have (hidden if you like) choices. simple answer: more options == less testing == less stable code == more time spent bugfixing after releases other answer: more options == more effort to maintain == less time for actual development In your case: this touchpad was present in a single series from early 2014 (with a refresh in Oct 2014) and got replaced because of user complaints in the 2015 models. No device since had this touchpad and no device will have it. So my motivation to put a new option in that I'll have to support forever for a device that's 3 years old and won't come back is... limited ;) I'll fix the bug in that you can't click unless you lift the finger, once that one's fixed we can look at what else is needed. Meanwhile: let's not have more philosophical discussions on options here, you can move that to the wayland-devel list if you want. Here it's just me replying to it, which could get boring after a while.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>