Skip Menu |

This queue is for tickets about the Tcl-pTk CPAN distribution.

Report information
The Basics
Id: 125050
Status: resolved
Priority: 0/
Queue: Tcl-pTk

People
Owner: CAC [...] cpan.org
Requestors: CAC [...] cpan.org
Cc:
AdminCc:

Bug Information
Severity: Normal
Broken in: 0.92
Fixed in: 0.93



Subject: [macOS][known issue] mouse buttons 2 and 3 are swapped
On macOS (native 'aqua' windowingsystem), any mouse button 2 ("right-click") functionality is bound to mouse button 3 ("middle-click"; n.b., many mice and trackpads don't have a third mouse button), and vice versa. This appears to be historically correct behavior since on Windows, Linux, and X11 on Mac, the mouse buttons (left, middle, right) are ordered (1, 2, 3) respectively; whereas on Mac (aqua), it assigns the right mouse button as button 2 for backwards compatibility with older Mac software. Cf. https://wiki.tcl.tk/12987#pagetoc81e115ef, https://wiki.tcl.tk/14728 One workaround is for a Tk program to detect 'aqua' as the windowingsystem and assign buttons appropriately. Another is to rely on a package that detects the platform (e.g. VirtualMouse for Tcl/Tk). The widget demo program doesn't implement any workaround at the moment I guess Tcl::pTk is doing its job correctly then by not automatically reassigning mouse buttons depending on the platform. However, for TkHijack, it might be useful to document this behavior. My ideas so far are to: (1) discuss this behavior in the documentation for TkHijack, and (2) print a warning, if possible, once a program running with TkHijack attempts to bind to mouse buttons 2 or 3 when windowsystem is 'aqua'; and then provide the program maintainer two ways 'silence' the warning by loading either: (a) a pTk submodule that silences the warning and automatically swaps buttons 2 and 3, or (b) a pTk submodule that only silences the warning, and assumes the program maintainer implemented their own workaround.
Some widgets (e.g. Scrolled) already have their own built-in events for right-clicking. So those widgets might need to provide some workaround for aqua I imagine that with workaround (a) above, it could apply not just to the program code but also any widget code, while workaround (b) keeps button order as-is for program and widget code.
I've opened an issue with Perl/Tk regarding this, since the behavior for some widgets (e.g. Text) is inherited from borrowed code; and that maybe a common approach can solve this for both Perl/Tk and Tcl::pTk. https://github.com/eserte/perl-tk/issues/31
On Mon Apr 30 10:21:17 2018, CAC wrote: Show quoted text
> I've opened an issue with Perl/Tk regarding this, since the behavior > for some widgets (e.g. Text) is inherited from borrowed code; and that > maybe a common approach can solve this for both Perl/Tk and Tcl::pTk. > > https://github.com/eserte/perl-tk/issues/31
Thanks for working this Christopher. Unfortunately, I can't give the support to this package that I would like to. If you are interested, I can add you as a co-maintainer, so you update the packages yourself.
On Mon Apr 30 10:47:20 2018, CERNEY wrote: Show quoted text
> Thanks for working this Christopher. > > Unfortunately, I can't give the support to this package that I would > like to. If you are interested, I can add you as a co-maintainer, so > you update the packages yourself.
Hi Mr. Cerney, thanks for replying. I would appreciate being added. I'm also interested in improving the Tk::IDElayout module as well. I'm still fairly new to CPAN, so it will be a bit of a learning experience. I'm assuming the code repository is hosted on SourceForge; my ID there is "chrstphrchvz" if you'd like to add me.
I'm marking this as resolved for now. There's still probably a better way to approach this issue than to have  $widget->windowingsystem ne 'aqua' ? $existing-button : $aqua-button everywhere there's a bind to buttons 2 or 3.
For reference: there are some events for mouse buttons 2 and 3 that are handled by Tk and not Tcl::pTk, and were not mapped to the correct buttons in older versions of Tk.

For example, middle-clicking to paste any selected text below the cursor was fixed only as of 8.5.16 and 8.6.1, so it affects the Tk 8.5.9 included with recent macOS; see RT #127120.

Tcl::pTk might implement a workaround to effectively patch the Tk behavior at runtime if it detects an older version that is affected.