TclTk digitizer does not recognize right-click

[cmbarton]

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.

Michael

[cmbarton]

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).

[neteler]

See also

​http://trac.osgeo.org/grass/ticket/74#comment:7

on the same topic.

[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 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.

[cmbarton]

Replying to neteler:

See also

​http://trac.osgeo.org/grass/ticket/74#comment:7

on the same topic.

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.

[cmbarton]

Replying to 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 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.

[cmbarton]

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.

[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.

[marisn]

v.digit mouse button patch for 6.5

[marisn]

Replying to 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.

Michael, please, test attached patch for 6.5.

[cmbarton]

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)

[cmbarton]

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"} {
		
		# right-click is acting like a middle-click...
		bind .screen.canvas <ButtonPress> {
			if { %b == 3 } {
				c_update_tool %x %y 2
			} else {
				c_update_tool %x %y %b
			}
		}
		# option + left-click for Mac equals middle-click
		bind .screen.canvas <Option-ButtonPress-1> { c_update_tool %x %y 3 }
	} else {
		bind .screen.canvas <ButtonPress> { c_update_tool %x %y %b }
	}

[cmbarton]

The following code works:

   # Requested by issue #1187
    if {[tk windowingsystem] eq "aqua"} {
		
#		# option + left-click for Mac equals middle-click
		bind .screen.canvas <Option-Button-1> { c_update_tool %x %y 2 }
		# right-click is acting like a middle-click...
		bind .screen.canvas <ButtonPress> {
            puts "button: %b"
			if { %b == 3 } {
				c_update_tool %x %y 2
			} elseif { %b == 2 } {
				c_update_tool %x %y 3
			} else {
				c_update_tool %x %y %b
			}
		}
	} else {
		bind .screen.canvas <ButtonPress> { c_update_tool %x %y %b }
	}

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()

[my test vector file is called "deleteme"]

Michael

[marisn]

Replying to 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.

[cmbarton]

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 ?

[cmbarton]

The following code fixes this bug report:

    if {[tk windowingsystem] eq "aqua"} {
		
#		# option + left-click for Mac equals middle-click
		bind .screen.canvas <Option-Button-1> { c_update_tool %x %y 2 }
#		# control + left-click for Mac equals right-click
		bind .screen.canvas <Control-Button-1> { c_update_tool %x %y 3 }

		# right-click is acting like a middle-click...
		bind .screen.canvas <ButtonPress> {
            puts "button: %b"
			if { %b == 3 } {
				c_update_tool %x %y 2
			} elseif { %b == 2 } {
				c_update_tool %x %y 3
			} else {
				c_update_tool %x %y %b
			}
		}
	} else {
		bind .screen.canvas <ButtonPress> { c_update_tool %x %y %b }
	}

I can go ahead and commit it.

Michael

[marisn]

Replying to 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.

[cmbarton]

This is now fixed for Mac. I don't know about Windows.

[cmbarton]

Just heard back on a Windows test. The buttons are OK.