homepage

In OS X tkinter the "two-finger scroll" generates <MouseWheel> events.
The following code:
#### bug.py
import tkinter
def mouse_wheel(event):
 print('Mouse wheel event')
tk = tkinter.Tk()
list = tkinter.Listbox(tk)
list.bind('<MouseWheel>', mouse_wheel)
for n in range(20):
 list.insert(tkinter.END, str(n**n))
list.pack(fill=tkinter.BOTH, expand=1)
tk.mainloop()
####
often throws a UnicodeDecodeError exception with a traceback like the one shown below when you do a "two-finger scroll" in the window.
Traceback (most recent call last):
 File "bug.py", line 12, in <module>
 tk.mainloop()
 File "/Library/Frameworks/Python.framework/Versions/3.1/lib/python3.1/tkinter/__init__.py", line 1009, in mainloop
 self.tk.mainloop(n)
UnicodeDecodeError: 'utf8' codec can't decode byte 0x84 in position 1: unexpected code byte
The value of the byte changes from time to time, and sometimes it may be possible to scroll a few times without producing the error.
This problem did not occur on my Mandriva 2010.2 system. I think it is specific to the Macintosh. It might possibly be related to:
http://bugs.python.org/issue834351 

This is almost certainly a bug in Tk. What OSX version are you using, and which python installer did you use?
One thing you could try is installing a matching copy of ActiveState's Tk (8.4 for the 32-bit build, 8.5 for intel-only builds of python 2.7 and 3.2)

I am running OSX 10.5.8 on this macbook. The Tcl/Tk package on the system is ActiveState Tcl/Tk 8.4.19.
I just installed Python 3.2 (r32:88452, Feb 20 2011, 10:19:59) from http://www.python.org/getit/releases/3.2/ and I am still seeing this bug. It does not occur with the Python 2.7 Tkinter package, which uses the same Tcl/Tk framework. So if it is a bug in Tk, it is harmless when used with Python 2.7. But, after all, it is not so surprising to see new UnicodeDecodeErrors when porting from Python 2 to Python 3.

The exception also occurs with Python 3.3 linked with Cocoa Tk 8.5. However, the it does not appear when Python 3.x is linked with Carbon Tk 8.4.

It looks like the problem is that the current Cocoa Tcl/Tk 8.5.x returns an incorrect MouseWheel event. Using the supplied test program and breakpointing in PythonCmd (around Modules/_tkinter.c:2027 in default), I found that it is being called from Tcl for MouseWheel events with an "argc" of 20, which looks suspiciously like the length of argv[1], "4302153816mouse_wheel", rather than the number of arguments which should be more like 3. It may also be an issue that affects Python because _tkinter still uses the older Tcl_CreateCommand interface rather than the newer Tcl_CreateObjCommand. The same Tcl behavior is observed with Python 2.7 _tkinter.c but there the bogus arguments are translated using PyString_FromString which is unaffected by the garbage arguments. It might be possible to workaround this problem in _tkinter but the next step is to open a Tcl/Tk issue against the Cocoa implementation and push for a proper fix there.
http://www.tcl.tk/man/tcl8.5/TclLib/CrtCommand.htm 

I've opened Tk Toolkit bug 3520202:
https://sourceforge.net/tracker/?func=detail&aid=3520202&group_id=12997&atid=112997 

I've added some comments to this on the Tkinter-dev mailing list, but to summarize, the bug is not reproducible on the Tcl side of the bridge, and so I am not clear what changes can be made in Tk's internals. It might e better to proceed with implementing a fix in Tkinter because the bug seems to occur at the level of Tkinter/Tk interaction.

A potential fix has been generated for Tk. I'll close this issue once the fix has been verified with _tkinter.

Tcl/Tk 8.5.12 has now been released. After installing ActiveTcl 8.5.12 for OS X, your 3.2 test case that previously readily failed for me no longer does. So I hope you also find that the problem is now resolved.

Thanks, Ned! It seems to be completely fixed by 8.5.12.

I recenly encuntered this error in OSX 10.9.2, using pthon 3.3 and 3.4 from Homebrew. I tried installing activetcl 8.6 package, but it still fails dependably.

I have resolved this by using the official Python distribution, rather than Homebrew's.