Mailman 3 August 2012 - Tkinter-discuss

Control position of Tkinter common dialogs?
by python＠bdurham.com Dec. 9, 2016

Dec. 9, 2016

Python 2.7 under Windows: How can we control the position of Tkinter's common dialogs? Here's what we've discovered: * Certain common dialogs always open up relative to their parent window * Certain common dialogs always open up centered on the user's desktop * All common dialogs appear to ignore the optional parent= parameter Questions: * How can we force a dialog to open up relative to its parent window? * How can we force a dialog to open up centered on the user's desktop? Background: import tkColorChooser as colorchooser import tkFileDialog as filedialog import tkMessageBox as messagebox # always open up relative to parent windows fileOpen = filedialog.askopenfilename() fileOpens = filedialog.askopenfilenames() fileSaveAs = filedialog.asksaveasfilename() color = colorchooser.askcolor() # always open up centered on desktop folderOpen = filedialog.askdirectory() messagebox.askquestion() Malcolm

6 9

Segfault in Image.PhotoImage on OS X
by Marc Culler Nov. 14, 2012

Nov. 14, 2012

This was reported here in February, but no debugging information was provided by the reporter: http://stackoverflow.com/questions/9142786/python-imagetk-photoimage-segfau… <view-source:http://stackoverflow.com/questions/9142786/python-imagetk-photo…> I can explain the nature of the problem, but I don't know how to fix it correctly. I am using the standard x86_64 Python 2.7.2 package from python.org and I have installed Active State Tcl/Tk 8.11. When I tried using easy_install to install PIL it would not load, claiming that _imaging.so did not exist. In fact, it existed but was only a thin i386 executable. So I compiled Imaging-1.1.7 with export CFLAGS='-arch i386 -arch x86_64' and export TCL_ROOT=/Library/Frameworks/Tcl.framework/Versions/8.5/Tcl I was then able to load the module. However, the following code produced a segfault: import Image import ImageTk import Tkinter W = Tkinter.Tk() Im = Image.open('test_image.jpg') x = ImageTk.PhotoImage(Im) The crash occurs in Tk_GetImageMasterData. More importantly, though, the crash was preceded by the following messages: objc[36554]: Class TKApplication is implemented in both /Library/Frameworks/Tk.framework/Versions/8.5/Tk and /System/Library/Frameworks/Tk.framework/Versions/8.5/Tk. One of the two will be used. Which one is undefined. objc[36554]: Class TKMenu is implemented in both /Library/Frameworks/Tk.framework/Versions/8.5/Tk and /System/Library/Frameworks/Tk.framework/Versions/8.5/Tk. One of the two will be used. Which one is undefined. objc[36554]: Class TKContentView is implemented in both /Library/Frameworks/Tk.framework/Versions/8.5/Tk and /System/Library/Frameworks/Tk.framework/Versions/8.5/Tk. One of the two will be used. Which one is undefined. objc[36554]: Class TKWindow is implemented in both /Library/Frameworks/Tk.framework/Versions/8.5/Tk and /System/Library/Frameworks/Tk.framework/Versions/8.5/Tk. One of the two will be used. Which one is undefined. Guessing that PIL was finding the System/Library/Frameworks/Tk.Framework instead of /Library/Frameworks/Tk.Framework, I tried hiding the system Tcl and Tk frameworks by renaming them. I was then able to create the PhotoImage and display it. I don't know where those messages come from, and I have never encountered them before. But I am guessing they are from OS X, since they are generated by an objective C program. Evidently _tkinter.so is able to specify which Tk.Framework to use. I don't know its mechanism for doing that. But, somehow, PIL is not doing it, and it ends up using the wrong one. A stack trace of the crash is below. - Marc 0x000000011517bccd in Tk_GetImageMasterData () (gdb) bt #0 0x000000011517bccd in Tk_GetImageMasterData () #1 0x0000000115183d9f in Tk_FindPhoto () #2 0x00000001014fbadc in PyImagingPhotoPut () #3 0x000000011502a05b in TclInvokeStringCommand () #4 0x000000010102142a in TclEvalObjvInternal () #5 0x000000010102261c in Tcl_EvalObjv () #6 0x000000010100646d in Tkapp_Call () #7 0x00000001000c102d in PyEval_EvalFrameEx () #8 0x00000001000c2d29 in PyEval_EvalCodeEx () #9 0x00000001000c0b6a in PyEval_EvalFrameEx () #10 0x00000001000c2d29 in PyEval_EvalCodeEx () #11 0x000000010003da80 in function_call () #12 0x000000010000c5e2 in PyObject_Call () #13 0x000000010001ebcb in instancemethod_call () #14 0x000000010000c5e2 in PyObject_Call () #15 0x00000001000ba5f7 in PyEval_CallObjectWithKeywords () #16 0x0000000100021e5e in PyInstance_New () #17 0x000000010000c5e2 in PyObject_Call () #18 0x00000001000be5f3 in PyEval_EvalFrameEx () #19 0x00000001000c2d29 in PyEval_EvalCodeEx () #20 0x00000001000c2e46 in PyEval_EvalCode () #21 0x00000001000e769c in PyRun_InteractiveOneFlags () #22 0x00000001000e78fe in PyRun_InteractiveLoopFlags () #23 0x00000001000e80e1 in PyRun_AnyFileExFlags () #24 0x00000001000fe77c in Py_Main () #25 0x0000000100000f14 in dyld_stub_strlen ()

4 5

tkinter and multiprocessing
by Mark Summerfield Aug. 30, 2012

Aug. 30, 2012

Hi, I'm trying to create a Tkinter application that uses multiprocessing in a separate module to do some work. In the Tkinter part I have this method of my Window ttk.Frame subclass: def report(self, future): with StatusLock: # Serialize calls to Window.report() if future.exception() is None: result = future.result() print(result) # TODO why does this lock the application? self.statusText.set(result.name) self.master.update() # Make sure the GUI refreshes StatusLock is a multiprocessing.Lock. self.statusText is a tk.StringVar. This function is called by a multiprocessing Future: future = executor.submit(action, arg1, arg2) future.add_done_callback(report) When I run the program with the last two lines of report() commented out it correctly prints each result on the console. But with the last two lines uncommented it prints one result and then the whole application locks at the self.statusText.set() call. According to the multiprocessing docs the callback is executed in the thread of the function it is passed -- so in this case in the GUI thread which is what is wanted. Any suggestions/help welcome:-) Thanks! -- Mark Summerfield, Qtrac Ltd, www.qtrac.eu C++, Python, Qt, PyQt - training and consultancy "Advanced Qt Programming" - ISBN 0321635906 http://www.qtrac.eu/aqpbook.html

1 1

tkinter error handling when tcl calls python functions
by Patrick Dunnigan Aug. 3, 2012

Aug. 3, 2012

Hi all, Scenario: I am transitioning a mature tcl package to python. As in interim step in the long process, I will use tkinter in a python script to call the tcl code. Since I have some common functionality already written in python, I am using the createcommand function to expose this to tcl. As a side note, there is no tk in this software, only using the tcl piece. Another side note: the useTk=0 argument appears to have no effect. Everything works nicely. However I have found that when the tcl code calls a python function and an error occurs in the python, the python error is not included in the tcl error stack. I've spent hours hacking away trying to figure it out, but now it's time to turn to the community. Here's a boiled down script that can be used to reproduce and illustrate: example 1, this is the best message I can get out of tcl, but doesn't include the error that occurs in the "hello" function: #!/usr/bin/env python from Tkinter import Tcl def hello(): # the error will occur on the following line ---> print z return tcl = Tcl() tcl.createcommand('hello', hello) try: tcl.eval('hello') except Exception as e: print tcl.getvar(name="errorInfo") raise e ./test.py while executing "hello" Traceback (most recent call last): File "./test.py", line 15, in <module> raise e _tkinter.TclError Example 2, this is what I would expect the tcl error message to include: $ python Python 2.7.1 (r271:86832, Jun 16 2011, 16:59:05) [GCC 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2335.15.00)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> print z Traceback (most recent call last): File "<stdin>", line 1, in <module> NameError: name 'z' is not defined The ideal error message would be something like (or with more traceback nesting if in a tcl procedure): Traceback (most recent call last): File "<stdin>", line 1, in <module> NameError: name 'z' is not defined while executing "hello" Traceback (most recent call last): File "./test.py", line 15, in <module> raise e _tkinter.TclError Thanks, Patrick

1 0