Skip to content

Improve responsiveness of triangular filter

The responsiveness of the filter is improved by adding two new metrics to the filter logic:

  • Firstly, the direction of the cursor movement is considered. If (in the default configuration) the filter is currently active and the user moves the cursor to the left (away from the content area), the filter stops intercepting the movement events. This results in a noticeable improvement in responsiveness without compromise the objective of the filter.
  • Secondly, a velocity metric (as already brought up in BUG 438950) is added. This ensures that a very slow movement of the cursor results in disabling the triangular filter. This, also, improves the the feeling of responsiveness significantly. Still, there is a need for the timer in the filter, as when the cursor has stopped its movement completely, it will no longer send HoverMove events to the filter, thus it wouldn't be possible to detect a complete stop of the cursor. Opinions on the actual threshold value for the velocity are very welcome.

This is a list of bugs I checked against to not introduce any regressions:

  • Triangle menu idle-hover reset doesn't work in kickoff (BUG 438950)
  • Mouse hover selection in search result persists across kickoff openings (BUG 454349)
  • Item not immediately select-able if cursor hovered over the item before opening Kickoff (BUG 456993)
  • Unmoving cursor continually reselects the menu item it's hovering over (BUG 455674)

Additionally, I ensured that the following things do not happen:

  • When scrolling and the cursor is contained in the category list, the selected categories should not be selected during scrolling.
  • When the menu is currently closed and opened with the meta key and the cursor is now hovering a category, do not select it and also do not select it when the cursor is moved in direction of the contentArea (so the user can directly select the favorites).

For the velocity metric, there is still some open questions. Firstly, the resolution of posF() isn't that accurate. Most of the times, it just returns something like QPointF(1.0, 0.0) for slow movements. Secondly, while I use timestamps to calculate the velocity, I'm not sure if the returned position value of posF() is dependent on things like the display resolution and scaling. So, the user experience might vary depending on those parameters. The question is if there is a more reliable way in Qt to retrieve the cursor velocity?

I have no touchscreen, so it would be good if someone that has one could test this patch.

This merge request depends on merge request plasma-desktop!1321 (merged) for Plasma Desktop and they should be merged together.

Merge request reports

Loading