Does this result in a behavior change such that a slow user with a mouse who clicks and then leaves the mouse in the same place for a moment will get a context menu? If so, I'm not sure that's a good idea. Lots of users aren't so great with non-touch input devices and this would result in a lot of frustrating interactions.

Press and hold isn't particularly intuitive.

When enabling this behavior (which is default off) a message is shown with the following content: "Close by double clicking:\n To open the menu, keep the button pressed until it appears."

Given that I'm not sure whether the base assumption that this is not intuitive holds. We clearly advertise this to the users. The behavior by the way was inspired by other components such as toolbar buttons with dropdown list which also implement press and hold.

Given that I'm not sure whether the base assumption that this is not intuitive holds.

Having to explain to a user what to do hardly qualifies as intuitive.

The behavior by the way was inspired by other components such as toolbar buttons with dropdown list which also implement press and hold.

Which doesn't make them less painful to use.

In D10855#214923, @broulik wrote:

Given that I'm not sure whether the base assumption that this is not intuitive holds.

Having to explain to a user what to do hardly qualifies as intuitive.

No guarantee that users would find the new way intuitive.

I kindly ask to look at the discussion ack in reviewboard when I implemented this feature. It was one of the most difficult changes to get in and this was the only solution we came up with which seemed to satisfy all concerns.

In D10855#214380, @ngraham wrote:

Does this result in a behavior change such that a slow user with a mouse who clicks and then leaves the mouse in the same place for a moment will get a context menu? If so, I'm not sure that's a good idea. Lots of users aren't so great with non-touch input devices and this would result in a lot of frustrating interactions.

Ignore this comment. I had misunderstood the patch and the underlying feature itself. I rescind any and all concern regarding this patch.

In D10855#215256, @graesslin wrote:

I kindly ask to look at the discussion ack in reviewboard when I implemented this feature. It was one of the most difficult changes to get in and this was the only solution we came up with which seemed to satisfy all concerns.

where is that discussion? could it be linked here? (sorry, I have no recall of it so i am not sure even what to search for)

personally, I would find this behavior way more intuitive, for the menu button, i expect it to open the menu on click, no matter what i configured for double click which is a completely different action from the user POV (also given that Windows has this behavior since windows95 it's something pretty entrenched in the expected behavior for that menu button)
it's just.. a bit complicated to implement, but that's an implementation detail, not to influence the ui... unless it can't really be avoided.
Long press on desktop is generally bad, i know we have it for some toolbuttonsand for plasmoid handles, but none of them are optimal, toolbuttons should definitely be solved, for plasmoids a bit more difficult, but should be improved as well

looking at the code, it seems to make sense to have a delay that corresponds to the double click interval, that may make the popup feel not super immediate(so the timer stuff is important is enabled only when the double click to close is enabled), but better than the unpredictable and undiscoverable long press.

I found https://git.reviewboard.kde.org/r/103995/ but it references older changes which I just didn't find with git log.

on the link i see mostly the motivation as a personal opinion of Thomas L.
The fact i kinda defend this diff is that the vdg is pushing to limit and drop the long press buttons menus on most places.
this is a thing i think should take proper discussion in the vdg and codified as a specific HIG, whatever the final outcome is

So, what shall we do with this?

Ping.

Why is the press and hold timer still needed? It should be enough to only test on double click expiration with this patch and open the menu on release of mouse button afterwards. We should accept this behavioral change in order to reduce code complexity (people should automatically understand that the menu opens from now on on button release after they have experienced it once trying it with long click). But if you want to split this up in a second patch I'm fine with it.

Otherwise I'm in favor of the change.

So do you want to change this diff or put it in a second diff?