Tkinter problems with Tcl/Tk 8.5
Hello, I am a Tcl/Tk core developer. I'm trying to resolve some bugs that have surfaced in Tkinter with Tcl/Tk 8.5. 8.5.0 is very near release, and I'm hoping we can determine where the problem is, and resolve it soon. http://sourceforge.net/tracker/index.php?func=detail&aid=1851526&group_id=12997&atid=112997 It seems very peculiar how the text widget's bbox is returning a Python-like list and therefore breaking the Tcl callback. I haven't thus far been able to determine which python method is causing that, or if it's something related to the hooks you have added. The same problem doesn't occur with 8.4. It also has been suggested by some on the Tcl core team (during discussions about this bug) that you probably shouldn't be using Tcl_GetObjType and relying on the registered Tcl_ObjTypes, however I'm not sure of a way to get what you need otherwise. Tcl 8.5 now supports big integers, so I think some changes may be needed in _tkinter.c for that. The list internal rep has changed as well, and I'm not sure if that will affect you. Another developer also pointed out that the text widget is returning a Tcl_Obj with a list type, rather than a string for the bbox subcommand, so that could be related to this bug. I hope that we can work together to resolve the issues you may have with Tk. George -- http://www.xmission.com/~georgeps/ http://whim.linuxsys.net http://code.google.com/p/megapkg/ http://code.google.com/p/opennexx/
Hi George, I hope I can find some time next week to look into this in more detail, but please let me respond to this first. In Python, objects have a fixed type, given to them at the point of creation. Also, it is common in Python to use multiple types, not just a single one (say, string). So to convert between Tcl objects and Python objects, we would like to preserve type information as much as possible. To do that, _tkinter has two functions: AsObj (converting PyObject to Tcl_Obj), and FromObj (converting Tcl_Obj to PyObj). We map the well-known (registered) types 1:1 to appropriate Python types, and have a default for the rest. If Tcl_GetObjType was not available, I see no other way but to convert everything through strings, which would put the burden of typing things onto the Tkinter user (or perhaps on Tkinter, to type the well-known commands). Regards, Martin
I have now studied this in detail, and fixed it in Python's trunk; see the tracker item for details. In short: - IDLE redirects all widget sub-commands, either calling an overridden definition, or the original Tk command. - in the redirection of "bbox", Tk 8.4 would return a string, whereas 8.5 now returns a list. - _tkinter converts the string to a Python string, and the list to a Python tuple - IDLE returns the Python value to _tkinter, which in turn converts it to a string. This leaves the 8.4 string unchanged, but converts the 8.5 tuple into something like "(10, 10, 20, 20)". - Tk interprets it as a list of numbers, choking as "(10," is not a meaningful number. The fix is to return an ObjResult to Tcl from a Python callback. I'm skeptical about back-porting this to 2.5, as it may affect behavior. So for 2.5, we probably have to recommend not using Tk 8.5. There are a number of additional incompatible changes. For example, text::index returns textindex objects now, where it used to return strings. I have fixed that in Tkinter, which converts the textindex back to a string. I'm sure there are other places where Tk 8.5 will break existing Tkinter applications. Regards, Martin
Hi George, I hope I can find some time next week to look into this in more detail, but please let me respond to this first. In Python, objects have a fixed type, given to them at the point of creation. Also, it is common in Python to use multiple types, not just a single one (say, string). So to convert between Tcl objects and Python objects, we would like to preserve type information as much as possible. To do that, _tkinter has two functions: AsObj (converting PyObject to Tcl_Obj), and FromObj (converting Tcl_Obj to PyObj). We map the well-known (registered) types 1:1 to appropriate Python types, and have a default for the rest. If Tcl_GetObjType was not available, I see no other way but to convert everything through strings, which would put the burden of typing things onto the Tkinter user (or perhaps on Tkinter, to type the well-known commands). Regards, Martin
I have now studied this in detail, and fixed it in Python's trunk; see the tracker item for details. In short: - IDLE redirects all widget sub-commands, either calling an overridden definition, or the original Tk command. - in the redirection of "bbox", Tk 8.4 would return a string, whereas 8.5 now returns a list. - _tkinter converts the string to a Python string, and the list to a Python tuple - IDLE returns the Python value to _tkinter, which in turn converts it to a string. This leaves the 8.4 string unchanged, but converts the 8.5 tuple into something like "(10, 10, 20, 20)". - Tk interprets it as a list of numbers, choking as "(10," is not a meaningful number. The fix is to return an ObjResult to Tcl from a Python callback. I'm skeptical about back-porting this to 2.5, as it may affect behavior. So for 2.5, we probably have to recommend not using Tk 8.5. There are a number of additional incompatible changes. For example, text::index returns textindex objects now, where it used to return strings. I have fixed that in Tkinter, which converts the textindex back to a string. I'm sure there are other places where Tk 8.5 will break existing Tkinter applications. Regards, Martin
participants (2)
-
"Martin v. Löwis" -
George Peter Staplin