Opened 9 years ago

Closed 8 years ago

Last modified 4 years ago

#6841 closed bug (fixed)

incomplete "clicks" mouse message filtering

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

Description

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.

Change History (6)

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

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

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

comment:4 Changed 8 years ago by bonefish

Resolution: fixed
Status: newclosed

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

comment:5 Changed 8 years ago by 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.

comment:6 Changed 4 years ago by pulkomandy

Blocking: 7932 added
Note: See TracTickets for help on using tickets.