Fix expand/collapse when using reset/presets lib buttons. #17987
Conversation
TurboGit
added
bugfix
|
Are you going to fix the iop modules (on/off button) under a separate PR? I won't have time to test this until this evening |
If this PR is working fine after testing I'll fix the iop on/off. |
|
For normal popup-up menus, a subtle behavior is that you can click-hold, move the mouse down to the item you want and then release to activate it and close the menu. So one click (and "drag") rather than click+move+click again. This worked for example for the instance button popup menu. Moving the button activation to button-release breaks that behavior. For an alternative, for iops, see 1995178 This should work for libs as well, but would require a separate callback for the "arrow" (expand) button and the header itself, whereas they now share the same (so that ignoring clicks on buttons, as the commit above does, would disable the arrow). EDIT: now implemented for libs as well, in 8255116 |
|
@dterrahe : Thanks a lot your version works quite well for lib & iop. I'll close this PR. |
|
@kofa73 pointed me to this thread... I have an issue with the diffuse or sharpen module in Windows...no other module that I have tried but clicking the hamburger selects directly a preset...its like the pop-up menu does not behave as it should.... That module has a long list of presets and it seems most times to land on deblur medium or one that is close rather than just bringing up the list... I will have to dig deeper to see what is up on my end...but I don't recall any thing that i changed...THis is behaving this way on my previous build from a few days ago and lat night which was 5.1.0 Other modules seem to behave as usual.... |
|
This would happen if the preset list were so long that it could not fit completely either below or above the button. It would then end up obscuring the button and be underneath the mouse immediately after it was pressed. When you then release the mouse, this is interpreted as selecting the preset immediately underneath it. If you don't want to select that one you can continue to hold the mouse button and move to the preset you want before releasing it. I'll try to think if there's a clean way to detect this situation and avoid having the button release act as a selection if the mouse hasn't moved since pressing the button. Related, it would be nice if presets could be grouped, like styles, using |, and put in multi-level submenus so that the top level doesn't get too long. Probably not high priority for most and needing support in multiple places (preferences dialog for example). |
|
I think you are spot on...I also didn't know about holding the click so I can do that for now and I agree that being able to group things wherever it makes sense would be a nice addition....thanks for taking the time to rationalize this for me... I appreciate it as always.... |
No description provided.