Closed ratijas closed 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.
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:
libinput-gestures
, which starts up like a rocket, takes up 30KB of space, and has more features and configuration options than an iPhone. Q.E.D. Curtain. Period.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.
@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.
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:
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.
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.