Showing dialog in non-main thread - python

I have a non-GUI program that sometimes needs to display a dialog to user.
The problem is that my program runs in an infinite loop and when I show a dialog in this loop the execution of program halts until the dialog is dismissed and this is not wanted because my program loop is a background service that must be responsive all time. So I tried running the dialog showing code in another thread but it doesn't work properly: The dialog is shown only one time/the first time and subsequent calls show nothing.
How can I solve this problem?
This is a sample code for you to test the situation:
import tkinter
import tkinter.messagebox
import threading
import time
def messageBox():
root=tkinter.Tk()
root.withdraw()
tkinter.messagebox.showinfo('dialog', 'test')
root.destroy()
while True:
threading.Thread(target=messageBox).start()
time.sleep(3)
I use Python 3.3.4 on Windows XP

My suggestion is to make your dialog a separate script, and use the subprocess module to display the dialog in a separate process.

Related

How can I run a function without interrupting my tkinter mainloop, but also send information from that function to widgets in my mainloop?

Apologies if this has been asked before, but I couldn't find a clear answer. I'm writing a GUI to control a motor from a raspberry pi, and it's on a touchscreen. I've written some code which opens the built in matchbox keyboard when the Entry widget comes into focus, but this halts my entire tkinter window in the background, meaning that the user cannot see what they are entering appear in the Entry until they have closed the keyboard, and also that the screen often tears and looks horrible when it hangs in the background. Is there anyway to run this command:
def createNumpad(event=none):
os.system('matchbox-keyboard numpad')
so that the tkinter window doesn't freeze while the keypad is open? Thanks!
This is the relevant code from a SO answer changed to fit Tkinter:
import subprocess
def createNumpad(event)
try:
subprocess.Popen(["matchbox-keyboard", "numpad"])
except FileNotFoundError:
pass
def deleteNumpad(event):
subprocess.Popen(["killall","matchbox-keyboard"])
#
entry.bind("<Enter>", createNumpad)
entry.bind("<Leave>", deleteNumpad)

How to hard quit a Tkinter program

My Python program consists of two parts, one gets user credentials through an Tkinter and passes it to the other script which then processes them.
It works fine but the only problem is that although my GUI passes data and then the processing script starts its work, The GUI starts not-responding and causes havoc as it freezes until the download completes (which could potentially take hours)
I create an object of the Interface class in the processing script by importing the GUI script
root = Tk.Tk()
root.title('Coursera-dl')
root.geometry("345x100")
app = GUI.Interface(root)
app.mainloop()
This is my GUI script's destruct method defined in a Class which is executed automatically after the data has been received by the processing script: However when the user clicks 'OK' the GUI freezes and doesn't exit and If I force quit it, the processing script also ends as python.exe is terminated
*code*
....................................
def destruct(self):
if tkMessageBox.askokcancel(title=None,message='Download would start upon closing the Interface, If any changes are to be made to the credentials Please do so by selecting Cancel'):
self.quit()
How can I make my program so that when the user clicks on 'OK' the GUI quits safely and the processing script does its work
root.quit() just Bypasses the root.mainloop() i.e root.mainloop() will still be running in background if quit() command is executed.
Use root.destroy()
this will stop root.mainloop() itself but it wont close the python program and everything will still be ran just without the GUI

Closing threaded Tkinter window

I use a Tkinter window to visualize some output of my programm. The window is threaded (see basic structure below) and basically it works quite fine. So far, I only have trouble closing the window. When I clicke the "X" button for closing the window it works.
However, when I call the Monitor.close() method from the main programm that starts the monitor thread, the window just freezes (e.g., it doesn't react on clicking the "X" button) and the thread monitor keeps running. Thus, the main program does not exit.
So, at the moment, I also have to close first the window "manually" by clicking the closing button and then the main program. Not a big issue, but it would be great, if the main program could close the window by itself. Any hints?
Thanks and best regards,
Christian
class Monitor(threading.Thread):
def __init__(self):
threading.Thread.__init__(self)
self.start()
def close(self):
self.root.quit()
self.root.destroy()
def run(self):
self.root=Tkinter.Tk()
self.root.protocol("WM_DELETE_WINDOW", self.close)
self.root.mainloop()
Python Threading and Tk(inter) used in this way do not mix well, as they violate the Tcl/Tk threading model of using Tk just from one thread.
It works great with message passing though, just not with direct calls from a thread. So you need to add some message passing via Queue to this.
Have a look at http://effbot.org/zone/tkinter-threads.htm for an example.

What is the difference between root.destroy() and root.quit()?

In Python using tkinter, what is the difference between root.destroy() and root.quit() when closing the root window?
Is one prefered over the other? Does one release resources that the other doesn't?
root.quit() causes mainloop to exit. The interpreter is still intact, as are all the widgets. If you call this function, you can have code that executes after the call to root.mainloop(), and that code can interact with the widgets (for example, get a value from an entry widget).
Calling root.destroy() will destroy all the widgets and exit mainloop. Any code after the call to root.mainloop() will run, but any attempt to access any widgets (for example, get a value from an entry widget) will fail because the widget no longer exists.
quit() stops the TCL interpreter. This is in most cases what you want, because your Tkinter-app will also stop. It can be a problem, if you e.g. call your app from idle. idle is itself a Tkinker-app, so if you call quit() in your app and the TCL interpreter gets terminated, idle will also terminate (or get confused ).
destroy() just terminates the mainloop and deletes all widgets. So it seems to be safer if you call your app from another Tkinter app, or if you have multiple mainloops."
taken from http://www.daniweb.com/forums/thread66698.html
The tkinter.Tk "quit" method exits the "mainloop" event-handler, and "destroy" destroys all the embedded widgets and only then exits the "mainloop". So is "destroy" the better of the two? Well, sometimes not. If "destroy" fails to destroy all the widgets for some reason, then "mainloop" is never exited and Python locks up. It can be better to just let Python shut things down in an orderly manner at the end of the script.
For example, if you embed a Matplotlib plot in a Tkinter window, that is useful because Matplotlib's own widgets are somewhat clunky to use. Unfortunately, if you then try to close the window by clicking the usual "X" in the title-bar, the window closes alright but leaves Python running. If the script had been started from a terminal, you'd have to mash Ctrl-C for a couple of minutes to get the prompt back. The reason being that the window-close event is bound to "destroy" which does not destroy the Matplotlib objects but leaves them orphaned.
The fix is to bind the window-close event to "quit" instead. But... if the script is started in a Tkinter-based IDE like IDLE, then that creates a new problem in that the window does not close because IDLE holds Tkinter running. So now "destroy" must be added after the mainloop. Finally, all is well.
Below is a minimal example of a Matplotlib plot that can be inverted with a press of a Tkinter button. Its window can be closed without problems. But if the windows-close event had been bound to "destroy" instead of "quit" then a locked-up Python process would remain.
#!/usr/bin/env python3
import tkinter as tk
from matplotlib.backends.backend_tkagg import FigureCanvasTkAgg
import matplotlib.pyplot as plt
root = tk.Tk()
data, = plt.plot([0,5,3,4,-5,3])
canvas = FigureCanvasTkAgg(plt.gcf(), master=root)
invert = lambda: (data.set_ydata(-data.get_ydata()), canvas.draw())
tk.Button(master=root, text="Invert", command=invert).pack()
canvas.get_tk_widget().pack(fill=tk.BOTH, expand=1)
root.protocol("WM_DELETE_WINDOW", root.quit)
root.mainloop()
root.destroy()
Edit: I'll add that by binding the window-close event to both methods, you can avoid adding a line after the "mainloop", should that be desirable for some reason:
root.protocol("WM_DELETE_WINDOW", lambda: (root.quit(), root.destroy()))
My experience with root.quit() and root.destroy() ...
I have a dos python script, which calls a tkinter script (to choose from set of known values from combobox), then returns to the dos script to complete other things.
The TKinter script I've added onto the parent script. I may convert all to tkinter, but a combo works for the time being. It works in the following way:
To get rid of the windows box after selection was implemented, I needed to
1) root.quit() inside the callback function where all my keypresses were being processed.
2) root.destroy() after mainloop to destroy the windows box.
If I used root.destroy() inside the callback, I got an error message saying tkinter objects were no longer accessable.
Without the root.destroy() after mainloop, the windows box STAYED ONSCREEN until the whole parent script had completed.

TKinter windows do not appear when using multiprocessing on Linux

I want to spawn another process to display an error message asynchronously while the rest of the application continues.
I'm using the multiprocessing module in Python 2.6 to create the process and I'm trying to display the window with TKinter.
This code worked okay on Windows, but running it on Linux the TKinter window does not appear if I call 'showerror("MyApp Error", "Something bad happened.")'. It does appear if I run it in the same process by calling showerrorprocess directly. Given this, it seems TKinter is working properly. I can print to the console and do other things from processes spawned by multiprocessing, so it seems to be working too.
They just don't seem to work together. Do I need to do something special to allow spawned subprocesses to create windows?
from multiprocessing import Process
from Tkinter import Tk, Text, END, BOTH, DISABLED
import sys
import traceback
def showerrorprocess(title,text):
"""Pop up a window with the given title and text. The
text will be selectable (so you can copy it to the
clipboard) but not editable. Returns when the
window is closed."""
root = Tk()
root.title(title)
text_box = Text(root,width=80,height=15)
text_box.pack(fill=BOTH)
text_box.insert(END,text)
text_box.config(state=DISABLED)
def quit():
root.destroy()
root.quit()
root.protocol("WM_DELETE_WINDOW", quit)
root.mainloop()
def showerror(title,text):
"""Pop up a window with the given title and text. The
text will be selectable (so you can copy it to the
clipboard) but not editable. Runs asynchronously in
a new child process."""
process = Process(target=showerrorprocess,args=(title,text))
process.start()
Edit
The issue seems to be that TKinter was imported by the parent process, and "inherited" into the child process, but somehow its state is inextricably linked to the parent process and it cannot work in the child. So long as you make sure not to import TKinter before you spawn the child process, it will work because then it is the child process that is importing it for the first time.
This discussion could be helpful.
Here's some sample problems I found:
While the multiprocessing module follows threading closely, it's definitely not an exact match. One example: since parameters to a
process must be pickleable, I had to go through a lot of code
changes to avoid passing Tkinter objects since these aren't
pickleable. This doesn't occur with the threading module.
process.terminate() doesn't really work after the first attempt. The second or third attempt simply hangs the interpreter, probably
because data structures are corrupted (mentioned in the API, but this
is little consolation).
Maybe calling the shell command xhost + before calling your program from that same shell will work?
I am guessing your problem lies with the X-server.

Categories