incomplete "clicks" mouse message filtering

[bonefish]

hrev39515

The "clicks" field of mouse messages should not indicate a multi-click, if:

• The previous click targeted another view.
• The modifiers changed between the click.

The effect of the missing handling of the former case can for instance be seen in Terminal: Clicking on the unused part of the menu bar and then clicking on a tab opens the title editing dialog (which is done when the "clicks" field is 2). BeOS R5 behaves the same way, BTW.

The latter would prevent that a click without modifiers followed by a click with Cmd-Ctrl held down minimized the window instead of bringing it to front.

[axeld]

The modifier thing would be easy to implement in the mouse add-on. The other suggestion is slightly more involved as the click count is already added in the device add-on.

IOW, the BView would need to remember the previous B_MOUSE_DOWN message it received, and eventually strip them out from the message.

[bonefish]

Replying to axeld:

The modifier thing would be easy to implement in the mouse add-on. The other suggestion is slightly more involved as the click count is already added in the device add-on.

IOW, the BView would need to remember the previous B_MOUSE_DOWN message it received, and eventually strip them out from the message.

IMO this is something that should be implemented in a central place in the app server. The target view handling could probably be done on the client side, but the same issue exists on the window level (cf. #6867 or try clicking near the Deskbar and afterwards, within the double-click interval, on an application item). It seems easiest to me to do that in a class like Desktop, through which all the mouse events seem to flow and which also seems to have all the needed information (including the target view).

BTW, I also think there should be a mouse movement threshold that resets the click count.

[anevilyak]

Replying to bonefish:

BTW, I also think there should be a mouse movement threshold that resets the click count.

I'd agree, the lack thereof currently results in a lot of apps, i.e. Tracker manually implementing threshold checking of their own since clicks == 2 in the mouse message isn't necessarily reliable in that respect.

[bonefish]

Fixed in hrev39623. Implemented in the Desktop's MouseFilter class. Seemed like the perfect place.

[axeld]

I think the input_server would be the more logical place for the modifier thing (to give the add-ons complete control), but otherwise, I like your solution.