On macos (Catalina, at least), when right-clicking a macro button to bring up the macro editor, the UI system is left in an awkward state after the editor is closed. A context menu appears uncalled for, drop lists don’t work right, and drawing elements sometimes flash oddly. This happens when I’m using a trackpad, where “right button” is tapping with two fingers. I don’t have a mouse with a right button to test with, so can’t clarify that.
I suspect this is because you are using a “right button down” event rather than a “right button up” event to open the editor in its modal state, and since the button is no longer down when the editor closes the UI system becomes lost, thinking the right button is still down. Just a guess though.
The UI problems persist until the application is completely restarted. This continues to happen in the .24 release.
Thank you for reporting this. I just tested using an internal beta of 9.25 and am experience similar on a High Sierra MacBook Pro I have here. We will investigate further and provide feedback here once we have more to share.
I’ve played with this a bunch today, and in the past, and it looks like it’s an issue with how the two-finger tap gesture is converted - this is my best guess.
If you Control+Click on the button (the “normal” way to get a right-click on Mac) everything works as expected.
Ah, I see that control-click does seem to work-around this UI problem.
I note in passing that the macro editor is launched on a right-button-down event instead of a right-button-up event. Mouse-button-up is considered a best practice for triggering UI controls in order to give the user a chance to cancel the action by sliding the pointer away from the UI control before releasing the button. It could be that changing the event handler to button-up rather than button-down may also fix my issue.
However, probably the best solution is to make the macro editor a separate button that brings up a dialog that can edit all six macros at once. That gets around the UI awkwardness, and also exposes the macro editing functionality visually – because of course it is troublesome that there’s no visual cue that right clicking on the macro buttons will bring up an editor.
I’m not triggering on ‘button up’, but on ‘context menu requested’, which is handled in an OS specific way by the platform framework we use (Qt) so it’s possible that the issue is theirs.
I’ve considered adding an ‘edit’ button, or just having an actual context menu appear that lets you pick which macro to edit - I suspect that would work because it would be actually triggering a context menu, then closing it, which would probably make whatever internal state tracker I’ve angered happier.