Fixing PopUpMenu behaviour

[Pete]

This patch implements what I think is the consensus on the preferred PopUpMenu behaviour in response to various mouse actions. It is not subject to the constraints of #7022, which doesn't work correctly when, for example, the desired menu position is not exactly at the click point. It works as follows:

A (secondary) mouse click in the menu activation area (e.g. View) holds the menu open until the next click, whether the mouse-up is outside or inside the menu itself.

A slower press and release will always close the menu, selecting and returning any item the cursor is over at the time.

This now works wherever the menu is designed (or happens) to appear. There is no need to constrain default 'openAlways' or 'clickToOpenRect' settings, which however may be used as always to modify the default.

It distinguishes between a "click" and a "press" via the double-click_speed user preference (which is how BeOS also distinguishes them.

[Pete]

PopUpMenu.diff (from hrev40241)

[dancxjo]

Menus seem to work as I expect them to with this patch; if it corrects the problems that Pete is concerned about too, that'd be great...

[Pete]

Replying to dancxjo:

Menus seem to work as I expect them to with this patch; if it corrects the problems that Pete is concerned about too, that'd be great...

Excellent! Quick checking job, there... (:-)) Thanks!

[leavengood]

I'll need to test this patch but it may indeed be better behavior. The patch certainly looks fairly simple. I'll try to apply this tomorrow and test it out.

But keep in mind you are definitely in the minority in liking the click-and-hold paradigm. I'm also still not convinced by your comment in #7022. I specifically tested opening the menu in a corner and purposely wanted the menu to stay open in that case and require another click to select or close. That is the best behavior for most users. If this patch doesn't address that I probably won't want to commit it. But I'll need to test before making judgement.

Since I worked on #7022 I'll also take ownership of this.

[Pete]

Replying to leavengood:

I'll need to test this patch but it may indeed be better behavior. The patch certainly looks fairly simple. I'll try to apply this tomorrow and test it out.

Good. Thanks.

But keep in mind you are definitely in the minority in liking the click-and-hold paradigm. I'm also still not convinced by your comment in #7022.

Not sure what you mean here. Do you mean click vs hold? I thought that in the discussion with Ingo and Stippi that it was decided that a click should alway lock a menu open, but if you hold the mouse down for longer you should not need a second click. (Originally I thought that a click should also close the menu without selecting anything, but I came to decide the above response was more appropriate.)

The reason 7022 worked for you but not me is that it assumes the click point is exactly the menu-top-left point, which is deliberately not the case in my menus.

I specifically tested opening the menu in a corner and purposely wanted the menu to stay open in that case and require another click to select or close.

That's what this patch does. If your click brings up the menu under the cursor it will stay open with no selection. A longer press lets you see the situation and you can decide whether to select or not, without needing a second click. I understood this was the majority preference!

[leavengood]

Well it seems to work quite well and this is a cleaner solution than what I implemented before. I committed the patch in hrev40306. Thanks!

[Pete]

Replying to leavengood:

Well it seems to work quite well and this is a cleaner solution than what I implemented before. I committed the patch in hrev40306. Thanks!

Great! Thanks!