+50€ by Paypal when initial requirements are met.
+100€ by Paypal for extra feature that Easystroke have. It can detect starting point of mouse gesture and underlying window. So if gesture has started above e.g. Firefox then only secondary button could invoke gesture.
That way e.g. RMB will invoke gesture; but if the underlying window is Firefox(blacklisted application), RMB will be captured by FF’s Gesurefy addon. In that case, kwin mouse gesture could only be captured by secondary button.
I’m not completely sure how exactly this rponsored work works, but I’m also willing to donate 25-50 dollars for this long forgotten, but loved feature (especially when easystroke is not working for me anymore)
I’ve decided that for the remaining month or so until Plasma 6.1 feature freeze, I’ll focus on getting the monitor brightness work over the finish line that I had started earlier. For 6.2, the plan is to then focus on getting mouse gestures upstreamed and hooked up with configurable actions. In addition to the links from the last post, note this discussion with KWin developers about outstanding questions and the way forward.
Hey folks, brief update and sorry for the long wait.
Full transparency: my monitor brightness work took way longer than I had anticipated and there are still a handful of bugs that I or the KWin people need to fix more or less urgently. But that feature is in, I anticipate I won’t spend much more than a week or two on this batch of improvements.
But also, we haven’t been entirely idle. Natalie Clarius and I submitted a grant proposal to NLnet which would provide funding for several months to work on touch gestures as well as stroke gestures (a.k.a. mouse gestures). If this gets accepted, I can make it my main focus. If not, I’ll still work on it but will have to do it in addition to other stuff that pays the bills. Whatever NLnet decides in the end, at least we came up with a somewhat detailed plan for what needs to be done to make this happen.
I figure that at this point, I’ll miss @fusionfuture’s 2024 deadline. I know you guys have been waiting patiently for this and I apologize for signing up for this before I was really able to make the time. If anyone still wants to grab this before NLnet gets back to us in about two months or so (I think?), by all means go for it. Happy to forfeit the bounty if someone else can get it done faster.
This sounds like great news as it was a show stopper for me.
(With that added, hopefully, only an application-independent on-screen keyboard [like Onboard on 5] missing.)
IMO you’ve proposed a solid plan for the task which importance has been recognized as an elected KDE goal. Therefore, I would like to revoke my restriction regarding deadline Best of luck with that grant proposal and godspeed.
God love you lot, I woke up so damned sore this morning, super depressing, then checked my email and this thread put a smile on my face and hope in my heart.
I don’t know how payment works for this but I’ve got 50 aussie dollarydoos with your name on it. I know that ain’t a lot but nor is the disability pension here If you need any of my time, you’ve got it.
No apology necessary - I am very satisfied with your response and look forwards to seeing this progress. Moving from ‘easystroke’ to using KDE’s native gestures was incredible, and I pray it can come home to roost on Wayland.
There are now about 1500 Dollar in the pot, if I count correctly. I am willing to give another 100 Dollar.
I’m still using Easystroke, but see its end coming with Wayland. So the new software should also have Easystroke’s functionality. So especially (and in contrast to the quite primitive old KDE-Gestures): Timeout-Gestures, Multiple-Button-Support, Scroll-Gestures, App-Specific-Gestures.
But one thing I do not quite understand: What is the advantage of doing all this coding-work only for KDE alone and not as a standalone app for all desktop-environments? Why do we want this only for us and not for the others?
Why not give the 1600 Dollars to mouse-actions for example? … or a fork of it. … to iron out their bugs?
Just to mention: As someone above already asked … I also absolutely do not understand why not everybody is using mouse-gestures!? … It makes life soo much easier. … lol … Why are they missing out on this precious jewel of usefulness?
A small bump from me as well! I was digging a bit today to see how the stroke recognition could actually be implemented, since @jpetso has already got a working proof of concept on github. From what I can understand, it looks like there are multiple new commits on xdg-desktop-portal-kde that should allow input capture even at a global level, or am I misunderstanding?
I’m currently working on adding mouse gestures to my plugin for customizing touchpad gestures. It’s close to being finished but I can’t say exactly when it’ll be done. You can try it right now by building the mouse-gestures branch. I don’t have the time to attempt upstreaming this, so it will remain a third-party plugin.
The features include (but are not limited to):
Wheel gestures
Press gestures
Stroke gestures (uses code from jpetso’s prototype)
Per-application gestures
Per-gesture activation buttons and modifiers
Start/end positions (not limited to just corners and edges)
Activation buttons can still be used but are blocked when necessary
Perhaps you might start by checking that they are both in place (this should have happened during make install and will have generated an error if it did not.)
If you start a new thread to avoid hijacking this one, we can work on troubleshooting this problem for you. Perhaps you would prefer to troubleshoot on github, you are welcome to @ me there (same name as here and I have posts in the existing issue/MR) and I will assist if I can.
So, the immediate question I had is, following @taj_ny’s work, will the approved NLnet project be partly obsolete or different in scope than originally proposed? But looking at it, I think the scope is still very much the same, because our project will focus on:
Upstreaming all of our gesture code into KWin proper.
Designing and implementing GUI settings, as opposed to InputActions’ primarily text-based configuration.
Exploring a possible cross-desktop protocol that lets applications declare their “local” actions in addition to Global Shortcuts, so that desktops can show them in a list and optionally assign gestures.
My current understanding is that these goals are largely distinct from what InputActions is trying to achieve, so we plan to go ahead as previously proposed.
I think I’ll get started by upstreaming the stroke recognizer into KWin, and then go from there. If there’s any particular piece of code in InputActions that would be a good candidate for adding to KWin, @taj_ny perhaps you have some thoughts on what work I should avoid duplicating.
It depends on how far you want to go with customizability. I looked at the grant application and I’d say the most useful code at the moment is in MouseTriggerHandler, which handles press, motion and wheel gestures, though it still needs some work and as of right now it has 0 tests so not exactly a good candidate.
Hello! I saw your blog post on the KDE community and came back to post again. Congratulations on getting your grant approved! that’s great news.
I’ve got a small suggestion as well, after reading your post/grant applications. If you go down the route of implementing stroke recognition directly into KGlobalAccel, with the current state of things it will have some heavy limitations compared to the old implementation. On the old one, shortcuts were inherently global, while the current shortcuts approach is more application focused. Sure, there are some default global ones, but they cannot be tied to a different keyboard combination.
I’ll go a bit off topic here to make an example:
In my case, I use gestures/keyboard shortcuts heavily to speed up common things, as an example let’s use opening a new tab in a browser.
On both Chromium and Firefox based browsers the default is CTRL+T, and right now there’s no way to create an alternate shortcut that will do the same thing (Such as binding CTRL+T to, for example, ALT+space). With the X11 implementation, it was trivial to create a mouse gesture, bind it to a key combination and then decide on what applications it would work. I had some working even on Dolphin.
Right now on KGlobalAccel you can add an application that’s not listed and it will allow users to add some shortcuts, but adding Chromium or Firefox won’t have an option to bind a shortcut to create a new tab, so in this example even adding mouse gestures wouldn’t really fix the issue.
I hope that whatever approach you go for in the end will allow for true global-wide shortcuts. And thanks in advance for your work!
We’ll start with mouse gestures triggering system-wide keyboard shortcuts as the first feature. It’s the easiest one to implement, and gets a long way to doing what many people want. KWin’s Xaver Hugl is also on board with this plan.
App-specific shortcuts approach are going to expand on this basic functionality, but they’re not meant to replace it. Ideally I’d want Chromium and Firefox to advertise their “New Tab” action with (default or hardcoded) “Ctrl+T” keyboard shortcut to the desktop, even if it’s not a global shortcut. Then the user could configure a gesture specifically for “New Tab” in System Settings, without adding a global “Ctrl+T” binding as workaround.
But that’s just the overall idea, there are a number of details to figure out until we get there, so we’ll tackle this once we get there
Best of luck with that grant proposal and godspeed.
If you need any of my time, you’ve got it.
