Opened 6 years ago

Closed 2 years ago

#9564 closed bug (no change required)

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

Reported by: X512 Owned by: axeld
Priority: normal Milestone: R1
Component: Servers/app_server Version: R1/Development
Keywords: Acer W500 Cc:
Blocked By: Blocking:
Has a Patch: no Platform: All

Description

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.

Change History (8)

comment:1 Changed 6 years ago by 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.

comment:2 Changed 6 years ago by X512

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

comment:3 in reply to:  2 ; Changed 6 years ago by 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).

comment:4 in reply to:  3 ; Changed 6 years ago by 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.

comment:5 in reply to:  4 ; Changed 6 years ago by 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.

comment:6 in reply to:  5 ; Changed 6 years ago by 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?

Last edited 6 years ago by X512 (previous) (diff)

comment:7 in reply to:  6 Changed 6 years ago by 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.

comment:8 Changed 2 years ago by axeld

Resolution: no change required
Status: newclosed

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

Note: See TracTickets for help on using tickets.