feat: configurable touch gestures

[julianjc84]

Really like the touch gesture implementation — great foundation to build on. I've made some
improvements based on a few of the suggestions:

• Made gestures fully configurable (finger count, sensitivity, natural-scroll per gesture)
• Added a recognition-threshold setting for gesture direction locking
• Split the gesture logic into its own touch_gesture.rs module for clarity
• Updated the wiki docs to cover all new options

[Atan-D-RP4]

Have you taken a look at the discussions on the gesture bindings upstream?

There's a lot of things to consider for this. And one thing I really want is exposing the gesture progress state somehow so users can make their own custom animated gestures through scripts and stuff.

Right now, I want this PR to only match existing touchpad gestures.

I'm open to building on your work here on a separate PR branch, or something, where we can experiment with more designs to the interface.

[Atan-D-RP4]

I would actually suggest that you PR this work upstream, at least as a draft, so that it'll have more eyes on it.

[julianjc84]

Thankyou, I will look upstream and take on recommended suggestions.

[julianjc84]

niri-wm#3771

[Atan-D-RP4]

Nice. Also, sidenote; is it that easy to work with GTK4/libadwaita in Rust? You built a whole GUI settings app with it!

Also, have you considered adding any scaffolding/infra for screen-edge gestures (only top/bottom, since the discussion in niri-wm#372 mentions we should leave left/right for apps)?

[julianjc84]

Ill be honest, ClaudeCode did all he heavy lifting in regards to building.

I have had a good read of the 372 discussion.
implementing features and having a GUI is problematic for corruption in how niri uses kdl configs.
I really like the work you did on LUA and will be looking at this and implementing.
from a GUI standpoint for easy config changes its the right way forward for having a corrupt free config UI editing.
It might not be the right way forward for the main niri project. but will make these custom developments way easier to expose / test / play.

[Atan-D-RP4]

I really like the work you did on LUA and will be looking at this and implementing. from a GUI standpoint for easy config changes its the right way forward for having a corrupt free config UI editing. It might not be the right way forward for the main niri project. but will make these custom developments way easier to expose / test / play.

Do you mean my lua or lua-stable branchs?

If so, then most of those I constructed with Opus 4.5 on the OpenCode harness back in December-January. When pricing on that was much more liberal through gh-copilot.

There's a ton of bloat, and over-engineering in them and I'm also exploring a better approach to doing with hooks into the core niri API using trampolines or something in a way that Hyprland does it. I was much less knowledgeable about the codebase and WL compositors and graphics in general back then.

Haven't gotten to cleaning that up yet.

[julianjc84]

I'm trying to get a better understanding of the config files.

The niri kdl config file is good when you manually editing it manually but when you have a gui interface that wants to write to it that's where things got complicated for me.

I'm a big fan of the gui to save config settings. config settings are going to get pretty big pretty fast with
Touchscreen
Touchpad
Mouse
Cursor
Etc.
Gesture bindings,
The only way I was able to make the gui work with the config file kdl was to have an include and it writes to its own separate file. I was having all sorts of corruption issues otherwise.
This is what got me thinking of the lua format.

Also the structure of the manual kdl file seems open and no defined standards just some concepts?