#1187: TclTk digitizer does not recognize right-click
---------------------------------------------+------------------------------
Reporter: cmbarton | Owner: grass-dev@…
Type: defect | Status: new
Priority: critical | Milestone: 6.4.1
Component: Tcl/Tk | Version: 6.4.0
Keywords: digitizer, v.digit, right-click | Platform: MacOSX
Cpu: OSX/Intel |
---------------------------------------------+------------------------------
A colleague just reported that the GRASS 6.4 TclTk digitizer (v.digit)
does not recognize a right-click with the OS X (Mac). I was able to
reproduce with with 6.4.1 svn, compiled a couple weeks ago. This happens
both with a mouse and a trackpad.
Since the wxPython digitizer has been disabled for GRASS 6.4, this means
that there is no digitizing available for anyone using a Mac. I don't know
if this affects people using other platforms, but someone ought to check.
To clarify a bit. A right click is being interpreted in the TclTk
digitizer as a middle button click. I can't seem to get it to recognize a
middle click at all (option-click on the Mac).
It looks like it's a Tcltk Aqua problem, where it sees right-click
(however it is generated) as button 2, where it should be button 3. When
using a 3-button scrollwheel mouse, I find that middle and right-clicks
are swapped.
So, the 'fix' for this right-click bug is to remap the button on OS X.
That still leaves us without a middle-click for trackpad users. So maybe
v.digit needs an alternative way to trigger a 'middle-click', or the
action it does (like undo vertex).
How does the wx vdigit handle this (I don't digitize in GRASS)? It does
recognize right-clicks correctly (according to Michael), but does it also
use middle-clicks for other actions, in which case it would also have the
same missing feature problem for trackpad users.
Replying to [comment:1 cmbarton]:
> middle click at all (option-click on the Mac).
option-click? I think this is only for X11. Part of the simulate
3-button mouse option.
The reverse of what I'd reported previously. Back in 2008, I mentioned
that a middle-click was acting like a right-click. Now, a right-click is
acting like a middle-click. Might be related though.
Replying to [comment:3 kyngchaos]:
> It looks like it's a Tcltk Aqua problem, where it sees right-click
(however it is generated) as button 2, where it should be button 3. When
using a 3-button scrollwheel mouse, I find that middle and right-clicks
are swapped.
>
> http://lists-archives.org/git/656542-mac-osx-and-gitk-right-click.html
>
> So, the 'fix' for this right-click bug is to remap the button on OS X.
That still leaves us without a middle-click for trackpad users. So maybe
v.digit needs an alternative way to trigger a 'middle-click', or the
action it does (like undo vertex).
>
> How does the wx vdigit handle this (I don't digitize in GRASS)? It does
recognize right-clicks correctly (according to Michael), but does it also
use middle-clicks for other actions, in which case it would also have the
same missing feature problem for trackpad users.
>
> Replying to [comment:1 cmbarton]:
> > middle click at all (option-click on the Mac).
>
> option-click? I think this is only for X11. Part of the simulate
3-button mouse option.
In TclTk, option-click could be bound to a middle mouse button. I'd also
prefer to have a double left click close figures (could be a right-click
alternative). This is more Mac-like (and maybe more Windows-like)
behavior.
I've had a report from a student that the Windows version of GRASS 6.4 is
also having confusion with the right and middle click. A standard way to
fix this could be the following:
1. add an alternate binding of a double left-click to end a line or close
a polygon (this is standard on most graphics programs Mac and Windows, and
even shows up on Linux). The same could be used to quit a tool.
2. for anything else that requires a right-click (e.g., a contextual
menu), provide an alternate binding for a key combination (it would be
Ctrl + left-click on the Mac; I'm not sure on Windows)
3. for anything that requires a middle-click, provide an alternate binding
for a key combination (option + left-click for Mac and perhaps alt + left-
click for Windows). For zooming, a one left-click zoom-in, like the zoom-
out would make zooming usable even without a middle button. Using the
middle-button for marking a zoom box corner is not needed since the TclTk
canvas supports rubber-band boxes. But this would require some
reprogramming. At a minimum, binding the box end to option-click (Mac)
and/or alt-click (Windows) would make this functional.
I looked to see if there was something in the TclTk code that I could
change to fix this issue. But it looks to me like the key bindings are set
in the C-code for v.digit. So someone else would need to make changes
there.
Replying to [comment:7 cmbarton]:
> I looked to see if there was something in the TclTk code that I could
change to fix this issue. But it looks to me like the key bindings are set
in the C-code for v.digit. So someone else would need to make changes
there.
Bindings in v.digit are tricky: toolbox.tcl just sends mouse click
together with mouse button code to particlular editing function (see
c_face.c and centre.c). Every editing function decides what to do on mouse
click (buttons 1 to 3). Adding more complex bindings (alt+mouse) can be
tricky (not today for me) as i.e. double-click at first time sends two
events - single click and double click.
It didn't work. I tried changing a couple things (Option-Button-1 to
Option-ButtonPress-1, and changing the order of the new key bindings), but
none of it worked. It also generated errors any time the mouse was moved
after starting a line or polygon like the following:
can't read "bind_scroll_list": no such variable
can't read "bind_scroll_list": no such variable
while executing
"lsearch -exact $bind_scroll_list $window"
(procedure "handle_scroll" line 5)
invoked from within
"handle_scroll -1 .screen.canvas"
(command bound to event)
Wait a minute. It sort of works. Still raises an error, but now if I do an
option-left-click, it registers as a right-click. Right-click is
registering as a middle-click. This is after changing your code to the
following:
{{{
# Requested by issue #1187
if {[tk windowingsystem] eq "aqua"} {
I did a puts %b and the mouse is registering correctly in TclTk. The
problem lies in c_update_tool. That is where the buttons are getting
switched.
I still get the bind_scroll error, but I don't think it is related. It
seems to be a different bug. Also polygons don't seem to be closing
correctly even though drawing ends.
Finally, it has long been a problem that when I go to register a database
entry after completing a vector object (point, line, area), it comes up as
"Cannot update table: DMBI-DBF driver error: SQL parser error: syntax
error, unexpected WHERE, expecting NAME process in 'where' in statement
update deleteme set where cat = 1 Error in db_execute_immediate()
Replying to [comment:11 cmbarton]:
>
> I did a puts %b and the mouse is registering correctly in TclTk. The
problem lies in c_update_tool. That is where the buttons are getting
switched.
c_update_tool is not touching button number, it's just passing it as-is to
registered tool update function. Tool decides what kind of action to take
depending on button number 1, 2 or 3. I.e. line.c @210 has defined 1=new
point; 2=Undo; 3=quit.
You can rearrange buttons or keys in any order as long as it results in
sending correct button number to c_update_tool function.
You can test Your TCL/windowing system mouse button order by launching
wish from CLI and executing:
{{{
bind . <ButtonPress> { puts "Plain %b" }
}}}
On my GNU/Linux system it gives: 1=left; 2=middle; 3=right.
As I wrote, more complex bindings (i.e. double click) are tricky as we
then have to delay single click event some ms before firing to detect
double/tripple/... click. This was a case for KDE some time a go and got
removed to make UI more responsive, as there are no more few ms delays on
every mouse click.
Hmmm. TclTk defines the left button as button 1, the right button as
button 2, and the middle button as button 3 for my system. This is how
Apple treats mouse buttons, and maybe Windows too (someone needs to check
this. So this is where the problem lies.
The script does a good job of remapping this but we'll need to add a
binding for Control-Button-1 so that it maps to 2 on the Mac. I just was
able to check on my laptop and this is not automatically registering as
button 2 with the trackpad.
The other issues I mentioned remain. Do you know where it is having a
problem with .bind_scroll ?
Replying to [comment:14 cmbarton]:
> The following code fixes this bug report.
> I can go ahead and commit it.
If it works for You, please, do so and close this bug with rXXX.
If there are problems with other windowing systems (win32), precise
description of existing bindings and wanted bindings is required.