bulletmark / libinput-gestures

Actions gestures on your touchpad using libinput
3.93k stars 241 forks source link

Fail to autostart (new version is incompatible with old config) #286

Closed ratijas closed 3 years ago

ratijas commented 3 years ago

Summary

Just updated AUR package, rebooted, and noticed that libinput-gestures failed to sutostart. As a user, I didn't receive any error messages or notifications. It just silently failed.

❯ libinput-gestures -l
libinput-gestures: session KDE+x11 on Linux-5.9.10-arch1-1-x86_64-with-glibc2.2.5, python 3.8.6, libinput 1.16.4
/bin/libinput-gestures: hash 6b7bec6cd2e54ef663f989ecf2fd8607
Gestures configured in ~/.config/libinput-gestures.conf:
# ...many irrelevant lines...
# and this is the one which causes trouble:
gesture pinch in 5 xdotool key alt+space
gesture pinch in 4 xdotool key alt+space
gesture pinch in 3 xdotool key alt+space
# ...many more irrelevant lines...
libinput-gestures: device /dev/input/by-path/pci-0000:00:15.1-platform-i2c_designware.1-event-mouse(event13): Elan Touchpad

Description

The issue here is the line gesture pinch in 5 ... in my config. It somehow worked until recently, but presumably because of this commit it refuses parsing it anymore.

As a result, I've experienced an unpleasant five minuted of debugging, and then spent another ten minutes writing up this issue to let you know that such silent fail is a horrible migration policy. Please, be a little bit more considerate next time you wanna break users' setup.

Solution

Removing the problematic 5-fingers line from the config certainly helps.

bulletmark commented 3 years ago

If you had done step 4 or 5 of the trouble-shooting section you would have seen the error message reported by libinput-gestures. I wrote this utility for my own personal use and then shared it on github. I have one touchpad to test against so there is inevitably some degree of "testing" I require of the community.

I fixed this issue with commit f4adc8f2e5da92626f09c7b7c34aecc2bf48fd54, as described there, and released new version 2.56.

ratijas commented 3 years ago

Thanks, @bulletmark, I appreciate that!

If you had done step 4 or 5 of the trouble-shooting section you would have seen the error message reported by libinput-gestures

You are implying that as a user I should be ready to go through the troubleshooting after every update. No, I really wouldn't wanna do that after every update of any tool on my system ;-)

I wrote this utility for my own personal use and then shared it on github.

I'm not sure how it happened, but it seems your home utility for personal purposes became quite vital tool for laptop owners in Linux community. You might be surprised to know that it is even my number-one argument when it comes to Windows vs. Linux debates:

That is to say, it's awesome.

Obviously no one can't blame you personally for doing whatever suits your needs. But when as a developer/maintainer of a popular tool, please be careful not to break user's setups (unless you don't care about them, that is).

If I were so bold, I'd suggest using *-git^AUR package for "testing" on willing users, and only after some time span (a week or so) actually releasing on "stable channel", if no major issues were raised during that period.

I believe I was upgrading non-git version of libinput-gestures, so I most definitely was not expecting that breakage to happen.

bulletmark commented 3 years ago

@ratijas , no I am not saying to go through the trouble-shooting section after every update. You said you "did not receive any error messages". This utility does report all errors to standard error, if KDE does not report those to you then that is unfortunate but either way, after you had a problem then you should followed the trouble-shooting guide and then you would have seen the error message.

Sorry, but I disagree with the whole concept of -git AUR packages and avoid them personally as a user, and as a package maintainer. It makes no sense to me that a package manager (e.g. yay) should ever install a "random" version, dependent only on the time/day you did the install. The number of users exposed to a -git version is probably minuscule after a week.

ratijas commented 3 years ago

Sorry, but I disagree with the whole concept of -git AUR packages and avoid them personally as a user, and as a package maintainer. It makes no sense to me that a package manager (e.g. yay) should ever install a "random" version, dependent only on the time/day you did the install. The number of users exposed to a -git version is probably minuscule after a week.

Well, whether you like it personally or not, that's kinda what -git packages were designed for. Say, rust has stable releases and nightly builds. Or you may have completely separate testing repositories (like official Arch Linux repositories have), but that's kinda not the case with AUR.

It only doesn't work, if a particular project doesn't care for the main branch being in a working state at any point in time — meaning they pile up features without testing, often breaking stuff, and only start fixing compilation issues in a last week before next release. Fortunately, there's not much projects like that out there, and more and more people setting up CI/CD pipelines which are cheap and easy to use there days.

More interesting info can be found at Arch Linux wiki on Official repositories.

Sorry, but I disagree with the whole concept of -git AUR packages and avoid them personally as a user, and as a package maintainer. It makes no sense to me that a package manager (e.g. yay) should ever install a "random" version, dependent only on the time/day you did the install.

I can't imagine how and why KDE would detect and report them in GUI without dedicated code on libinput-gestures side. How about I investigate the matter, and send a PR adding capability to send DBus notifications or show Qt/GTK dialogs?

The number of users exposed to a -git version is probably minuscule after a week.

To the best of my knowledge, AUR maintainers have access to download statistics for their packages. You'll never know until you try. :slightly_smiling_face: