https://bugs.kde.org/show_bug.cgi?id=402857
--- Comment #48 from Jakob Petsovits <[email protected]> --- (In reply to Blazer Silving from comment #46) > The mini-sprint produced > https://invent.kde.org/plasma/kwin/-/merge_requests/7620, > which is nowhere near ready. It's true that I should have gotten this merged a long time ago, and I take full responsibility for it still being in Draft. That MR actually works pretty well for what it's supposed to do. The integration into KWin makes sense from what I can tell, per-device activation buttons are supported, path simplification made it performant enough even for longer strokes. It is still lacking tests and a way to read actions via KGlobalAccel, which is the main reason why I haven't removed draft status yet. The main issue with that MR is that it's irrelevant in the context of this bug. The MR you linked is about stroke gestures (a.k.a. mouse gestures), whereas this is about touchpad and touchscreen gestures. What touchpad & touchscreen gestures need is infrastructure for KGlobalAccel to read (and perhaps write) user configuration for a trigger (gesture) to action mapping. At Akademy, Xaver proposed https://invent.kde.org/plasma/kwin/-/merge_requests/8085. This is also still in draft, but will help to make the config stuff happen. > I still say the best solution until it is complete is to stub > the existing gestures with a user-accessible toggle, which will allow > libinput-gestures to properly function. For the record, we also have https://invent.kde.org/teams/vdg/issues/-/issues/99 with a UX design that eventually found agreement between Natalie, Nate and myself. Andy may still have something to add to the discussion in the future, but it's a solid template for anyone who wants to get going on the settings. Which, to be clear, is still on my plate if at some point I figure out how to stop sucking and get actual work done again. I think that exposing a toggle instead of the full range of possible actions is a good intermediate goal. Starting with a toggle does not seem like a detour from implementing the full functionality. I was also thinking that this would be a good idea, we should absolutely do it that way. Still, the main thing that's still missing is the ability to read and write the config. From the mini-sprint, we also still have a proposal for the actual config file format, however that's still only in our shared document and I need to submit a KWin issue so the KWin guys can chime in. Either that, or they'll eventually beat me to it and do something entirely different. -- You are receiving this mail because: You are watching all bug changes.
