Simple :) I'm fine with the code, but not using QuickMenu, I don't have any opinion on the behaviour with the different type of gesture. Is it always convenient?
Pinging @jonnyl2 if he wants to test it.

Tested and it works well, thank you. Very convenient for short gestures. However, is it possible to make the position dependent on the end point of the gesture, rather than the starting point? For longer gestures across the whole screen, the QuickMenu otherwise appears on the opposite end of the screen after completing the gesture.

Technically, yes, although GestureDetector doesn't currently forward that information (and every gesture would have to be handled, and the data may not always make sense for all of them?).

As an example, here's how the swipe data is exported:

(See earlier in that function (Contact:handleSwipe) for how start_pos is computed, and how to get at the end contact instead via self.current_tev).

That could be forwarded as end_pos for gestures where it makes sense (most of the gesture detection code will have access to it, and might already have it processed in a ready-to-use format), and then the code use end_pos if available, or fallback to pos otherwise.

Thanks @NiLuJe. If someone would like to write the code I'm happy to test it, otherwise it also works fine with the current changes (most gestures are usually performed on a small area on the screen anyway -- especially to call a QuickMenu).

I don't use quickmenu so this is done on my end, not going to rework gesturedetector to find the gesture end, just this as it was quick and easy.

I don't use quickmenu

Ditto ;).

Fairly low hanging branch for interested parties, though ;).

Doesn't work with Profiles.
I will fix it (and maybe will make it optional for profiles, I used to the centered QMs).

The design question regarding the width, which one is better?

Current width factor 0.8

Width factor 0.7 (the last long item is shrinked)

Adaptive width based on the buttons width (a long item is in the list)

No long items in the list

Probably adaptive provided it doesn't adapt out of bounds?

And truncated if longer

No strong opinion. May be Adaptative with a min width of 0.5 or 0.6 or 0.7.

If I get a vote, my preference would be adapative width with no minimum, and a max width as in the last screenshot (0.8?).