chrstphrchvz
commented
6 years ago Another idea would be to define events that automatically correspond to buttons 2 and 3 depending on windowingsystem. Naïve names for these would be events named ButtonPress-Right, ButtonRelease-Right, etc. (although those are right-hand biased); and similarly for -Middle events; and maybe for completeness -Left events could also be defined for button 1. I don't know if this is a good idea, especially unless somehow Tcl/Tk were to consider the same approach.
Related to #24.
The numbering of middle and right mouse buttons depends on platform: Mac aqua (and classic as well—is this still supported?) designate the right mouse button as button 2 and the middle button as button 3, which is the opposite of what X11 on Mac, Linux/other Unixes, and Windows use. It appears to be 'intentional' that Tcl/Tk passes this mapping through to programs rather than attempting any automatic renumbering.
So at the moment, any events that normally happen with a right click are bound to the middle mouse button, which might not even be available depending on the mouse or trackpad. Nor is there a built-in keyboard modifier to emulate it (as there is for right click: control + left click).
Some Tk widgets have right-click events that are hardcoded to a specific button number, e.g. Text.
The quick workaround I have would be to check if
windowingsystemis'aqua'and bind button events appropriately. I'm willing to provide fixes like this for any cases I come across, but I'd like to discuss whether there's a more desirable/universal way of dealing with this.I found this issue while using Tcl::pTk, but it 'inherited' the behavior from Perl/Tk code it borrows. So any effort for solving this from Perl/Tk I'll consider passing along to Tcl::pTk and vice versa; see this issue I filed for some thoughts I had on more elaborate workarounds.