"clicks" field in B_MOUSE_DOWN message is reset on mouse move

[X512]

BeBook clearly says that: 1 for a single-click, 2 for double-click, 3 for triple-click, and so on. The counter is reset if the time between clicks exceeds the "Double-click speed" set by the user in the Mouse preferences. Note that the counter is not reset if the mouse moves between clicks.

Resetting clicks is a problem when using touchscreen because it's accuracy is not high and tapping the same point produces different positions.

I found some code in app_server that reset "clicks" field. Maybe other components also refuse double click if mouse is moved. It should be fixed too.

[axeld]

It doesn't matter what's in the BeBook in this case; for a mouse input it makes sense to remove the clicks when the mouse moved over a certain threshold (although it would be helpful if you would have linked the source in question when you already found it :-)).

Since we usually know the source of the clicks (and whether it was a mouse or not), we should instead enlarge the threshold considerably for touch screens. Even there, it doesn't make any sense to detect a double click on different corners of the screen.

[X512]

Personally I don't understand why clicks field is reset on mouse move. Why does it used and what benefits in it?

[bonefish]

Replying to X512:

Personally I don't understand why clicks field is reset on mouse move. Why does it used and what benefits in it?

The behavior prevents erroneous double-clicks. If you're a fast mouse operator, you can easily perform two single-click operations within the double-click interval (even when set reasonably short).

[X512]

Replying to bonefish:

The behavior prevents erroneous double-clicks.

Can you provide some real example of this case (in specific program doing specific action)? Mable there are better solutions other than reset on move exists for common usage.

If you're a fast mouse operator, you can easily perform two single-click operations within the double-click interval (even when set reasonably short).

Such users can make double click speed shorter.

[bonefish]

Replying to X512:

Replying to bonefish:

The behavior prevents erroneous double-clicks.

Can you provide some real example of this case (in specific program doing specific action)?

I'm pretty sure you can find at least one closed ticket referring to such a problem. Off the top of my head I can think of selecting adjacent list items.

Mable there are better solutions other than reset on move exists for common usage.

I'm not aware of any use case where you want to register a second click in a different location as a double-click, so I don't see why the burden of determining whether it really is a double-click should be moved to the application developers. As Axel wrote, for touch screens you might need to increase the distance for determining where it's no longer the same location, but other than that I think the current behavior is just fine.

If you're a fast mouse operator, you can easily perform two single-click operations within the double-click interval (even when set reasonably short).

Such users can make double click speed shorter.

Wrist and finger movement are independent from each other, so regardless how short you set the double-click interval, if it's long enough for a double-click it is also long enough for a click-move-click. Besides, the double-click interval needs to be lax enough that even on a slow day your double-clicks are still registered as such.

[X512]

Replying to bonefish:

I'm pretty sure you can find at least one closed ticket referring to such a problem. Off the top of my head I can think of selecting adjacent list items.

Yes, you are probably right. Distance based resetting is most simple to implement in it is application independent.

Replying to bonefish:

As Axel wrote, for touch screens you might need to increase the distance for determining where it's no longer the same location, but other than that I think the current behavior is just fine.

If so, how it's better to implement it? Checking presence of "be:tablet_x" and increasing reset radius?

[axeld]

Replying to X512:

If so, how it's better to implement it? Checking presence of "be:tablet_x" and increasing reset radius?

That would be the poor man's solution, but certainly acceptable, as we currently do not really have a protocol that would allow passing that information when registering the input streams with the app_server IIRC.

[axeld]

Since the current implementation works just fine, and we don't have touch screen support yet. I'm closing this one. Patches accepted anyhow.