Maximum travel distance // no timeout

[oredaze]

I propose an other mechanic for activating items - if the drag travels a certain maximum distance it activates. That would make it more consistent/predictable than the models we have right now (especially in combination with the no-click option). It will increase speed.

Also please add an option to disable the timeout. It would be unnecessary in this scenario and it would prevent accidental activations that happen to me right now.

[Schneegans]

Thanks for the suggestion! I fact, I played around with such an activation option in the beginning, but it's not as good as you might think. In fact, I am pretty sure that it will decrease speed and lead to more false selections. Let me explain why:

• If you set the distance threshold to a low value (let's say to 200 pixels): You have to move you mouse carefully in order to not overshoot! If you move your mouse by 400 pixels, you will instantly select a child of the selected submenu which is positioned in the same direction.
• If you set the distance threshold to a high value in order to prevent the above problem (let's say to 400 pixels): You'll have to move the mouse farther (which will be slower) and you will quickly approach your screen edges.

Both problems combined make up for quite a bad experience.

That being said, you can already achieve this behavior! In the advanced settings, you can reduce the Selection Timeout to 10ms and increase the Minimum Stroke Length to -- for example -- 400px.

[oredaze]

That being said, you can already achieve this behavior!

So I read this as: if the 10ms time passes it queues the activation, which immediately applies if you surpass the minimum stroke length? I have not thought about that interaction. I hope it's true. Did not think about the overshooting problem either, curious. I will test it when I get home and report.

[Schneegans]

No, the 10ms timeout will start once you passed the threshold. However, 10ms is very short and after a quick test, this seems to activate items quite reliably once the pointer is behind the distance threshold (I am pretty sure that the pointer position is polled less frequently, so the timeout will activate an item even if your mouse is still physically moving). Anyways, it will be enough for you to test the behavior! If you like it, we could consider reducing the lower limit of the activation delay to 0ms which then would really imply instant activation once the pointer moved beyond the activation distance.

In practice, there shouldn't be much of a difference though.

[oredaze]

Ok, so I played with it enough (I am using hover mode) and there is definitely some sort of inconsistency between the stroke length. 10ms doesn't sound like much, but apparently it is. Idk, it may be the many years of playing counter-strike, but I like to move fast. When I move slow the stroke length is consistent. Also I am precise enough to be very certain that I will not overshoot the items like in your first concern.

So... I don't know how you would want to do it, but please make the stroke length be always the same for us fast users.

[Schneegans]

Alright, I created #179. I'll see whether reducing the lower limit to zero milliseconds and handling this case in a special manner does the trick! Thanks again for the suggestion!

[oredaze]

You are awesome!

[oredaze]

I have some more observations of your nice program, if you are interested.
But I first want to establish some things, please bear with me.

So we have 3 ways to activate items, right... (i don't know how you name them): 1: mouse click; 2: activation key release after a drag; 3: hover mode. After playing around a lot I have determined that mouse clicking (1) is the slowest mode and thus not to be used; the best one is (2), because it is fast and you cannot make mistakes, unlike (3).

Next is the strength of fly-pie. It is mouse only use. Because it is a pie menu, right? If I am to use the keyboard to activate it, I may as well use just regular keyboard hotkeys. Pie menus are great because the items are next to the cursor starting position. Efficiency. Etc. As this is the case I have tried to bind my side mouse button to open fly-pie. I found 3 different ways to do that.

Now, in order to use mode (2) (the best one) we have to hold down a key, drag and release. Problem is only 1 of the 3 methods of binding keys work with key holding - the one that is giving me lagg. So much lagg that when I press the button fly-pie comes out noticeably after my mouse movement. I understand from an other discussion topic that you won't be providing bindings to mouse buttons like gnome-pie can. So my only option is to use mode (3).

We finally come to why I write all that in this topic: when using mode (3) I am experiencing very inconsistent stroke length no matter how much I try to get used to the movements (I am also experiencing that in (2) but there it doesn't matter). It must be the "selection timeout". I don't know if it is the polling time itself or a bug or the fact that operating systems are not a real time thing, but it is super inconsistent... I propose (again) the same thing at the very start of the thread - that polling of timeout be an option, rather than always on. And new option added - stroke length measurement, that is without polling. That 10ms sometimes feels like 300ms, some times feels like it is instant 0ms. One suggestion is maybe you can measure the pixels traveled and activate at a certain number.

Sorry for the big text. I know people are busy.
Thanks for the attention.

[Schneegans]

Yap, this sounds legit. My plan is to disable polling if the selection timeout is set to zero and to check the mouse travel distance instead.

Personally, I am using a Logitech mouse with programmable side buttons. They simulate key combinations - and I experience a significant activation delay on X11. Under Wayland, it is much faster though! Are you on X11 or Wayland? And I recently learned about key-mapper but haven't tried it yet. I suspect that it could work quite nicely, especially on Wayland...

[oredaze]

I am on X11. key-mapper is exactly the one I was talking about. You can hold keys with it, but laggs. I have not tried it under wayland though. But today the key-mapper service doesn't even start anymore. Idk what I did yesterday, trying out different ways to remap keys. I must have broken something.

[Schneegans]

Maybe you should try this on Wayland. I expect faster response times!

[oredaze]

Ok, I tried it on wayland and indeed it's fast. I guess that fixes my issues.
Thanks for the help.

[Schneegans]

#195 got merged to develop. If you want to, you can now try setting the Selection Timeout to zero!