I want to query a widget's size after changing its contents. Here's a demonstration:
import tkinter as tk
win = tk.Tk()
label = tk.Label(win)
label.pack()
def callback1():
label['text'] = 'hello world'
win.after_idle(callback2)
def callback2():
print('label width:', label.winfo_width())
win.after(0, callback1)
win.mainloop()
According to the documentation, callbacks queued with after_idle should only be executed when there's nothing else to do:
Registers a callback that is called when the system is idle. The callback will be called there are no more events to process in the mainloop.
And yet, callback2 is clearly executed before the label is resized, because the output of the program is this:
label width: 1
Even adding a call to update_idletasks() doesn't change this output. Only if win.update_idletasks() is called in both callback1 and callback2, the correct size is printed. I really don't understand why it's necessary to call it twice.
Question
Why is callback2 being executed before the label is resized? How can I ensure that label.winfo_width() returns the correct size?
Limitations
The main goal of this question is to understand how/when tkinter executes (idle) tasks. I want to find out how to correctly queue tasks so that they're executed only after the GUI has updated itself. I'm not really interested in workarounds such as these:
I'd prefer to avoid using update() because I don't understand how it causes race conditions or when it's safe to use. (In my real code, all of this would be executed inside an event handler, which the documentation explicitly states should be avoided.)
I also want to avoid using the <Configure> event. This is because there might be an arbitrary number of widgets changing size, and I cannot reasonably be expected to bind event handlers to all of their <Configure> events. I really just need a way to execute a callback function after all the resizing has taken place.
Related
global window
window = Tk()
window.geometry('300x200')
window.minsize(300,200)
window.maxsize(300,200)
window.configure(bg='black')
window.title("testupdate")
global outputtext
outputtext = tk.StringVar()
outputtext.set("starting window...")
my_label = tk.Label(window, textvariable = outputtext, bg = 'black', fg = 'white', font = 'terminal')
my_label.pack()
class ChangeLabel():
def __init__(self, text):
outputtext = tk.StringVar()
outputtext.set(text)
my_label.config(textvariable = outputtext)
Here's the main code: https://replit.com/#YourPetFinch/textadventure#main.py
I've been trying to make a text adventure game with Tkinter so I can package it all nicely as an app. I created a function that I can call from another file to update a label as the game output so I can keep the GUI setup simple, but I've been having a problem where the window won't show up until the code has finished running. I'm new to tkinter (and honestly not very good at Python in general) so this is probably a stupid question.
That's not how global is used. The global statement is only used inside a function, to state that you're going to modify a global. You can't actually make a global that crosses files, but your from gui import * will handle that.
The issue here is understanding event-driven programming. When you create a window, nothing gets drawn. All that does is send a number of messages to signal the core. The messages will not get fetched and dispatched until it gets into the .mainloop(). The main loop processes all the messages and does the drawing, which might queue up more messages.
So, you cannot use time.sleep(2) like that. As you saw, that will interrupt the process and prevent any drawing from being done. Instead, you will have to use window.after to request a callback after some number of seconds. The .mainloop monitors the timers, and will give you a call when time runs out. You cannot use time.sleep inside an event handler either, for the same reason; your GUI will freeze until your event handler returns.
Let's say we have three tkinter widgets: a label, a treeview and an Optionmenu (will be called 'menu' for short below). I successfully make the menu execute a function once an option is chosen. The brief function looks like this:
def data_process():
# do something takes time
def print_data()
data_process() # do something takes time too
# print stuff to treeview
def refresh_table(self, args):
label['text'] = 'Executing' # change label text to Executing
print_data() # a func. which takes time to run
label['text'] = 'Done' # change text to Done
label = tk.Label(parent, text = 'ready')
label.pack()
menu = tk.OptionMenu(parent, var, *list, command = lambda _:refresh_table(self, args))
menu.pack()
table = tk.Treeview(parent)
table.pack()
Function print_data is going to print something to a treeview widget (table). The label widget is like a status bar, telling users what's going on now. So the workflow that I attempt to do is:
Select an option in menu and call refresh_table.
Change label text to 'Executing'.
Execute print_data and print stuff in treeview.
When print_data is done, change the label to 'Done'.
Here is the thing. When I select the option, the program stocks (as expected) to do stuff. However, the label isn't changed to 'Executing' at the beginning. Instead, it's changed to 'Done' when the print_data is done executing (almost simultaneously). I suspect that the command refresh_table effects the target widgets once all demands are done. Because I does see the label flashes out 'Executing' but immediately shows 'Done'. Are there any thoughts about this situation? Any suggestion is appreciated. Thank you!
I suspect that the command refresh_table effects the target widgets once all demands are done.
That's true. Your GUI will update every time the mainloop is entered. While your function refresh_table is running, no events (like updating your label) will be processed, since those only occur during idle times (hence their other name, "idle tasks"). But because the UI isn't idle during the execution of refresh_table, the event loop is not accessible until all code in the function is done (because your whole program runs on the same thread) and the redrawing event is pending. You can fix this by calling update_idletasks, which will process all pending events immediately. Would be done like this (assuming that your main window is called parent and you are inside a class definition, the important thing is that you call update_idletasks on your main window directly after changin the label's text):
def refresh_table(self, args):
label['text'] = 'Executing'
self.parent.update_idletasks()
print_data()
label['text'] = 'Done'
There's also update, which will not only call pending idle tasks, but rather process basically everything that there is to process, which is unnecessary in your case. A very nice explanation why update_idletasks is mostly preferable to update can be found in the answer to this question.
Now i understand the concept of instance variables and classes, I've never had a problem with them before and I use them frequently. However when I make my MainWindow class, everything is peachy until i try accessing instance variables.
http://pastebin.com/tDs5EJhi is the full code, but at this point it's just placing labels and frames and whatnot, no actual logic is going on. The window looks fine and nothing bad happens.
My question comes to be when I try changing things inside of the window externally. I figured I could just make an instance of the class and change variables from there (namely instancevariable.ImageCanvas.itemconfig()) like i can normally, but Tkinter isn't being nice about it and I think it's a result of Tkinter's mainloop().
Here's the tidbit of my class MainWindow() that i'm having trouble with (ln 207)
...
self.C4 = Tk.PhotoImage(file="temp.png")
self.card4 = self.CardCanvas.create_image(120,46,image=self.C4, state=Tk.NORMAL)
#self.CardCanvas.itemconfig(4, state=Tk.HIDDEN) # < It works here
...
self.root.mainloop()
window = MainWindow()
window.CardCanvas.itemconfig(4, state=Tk.HIDDEN) # < It doesn't work here
That's how i learned how to edit instance variables. When the window pops up, the itemconfig command doesn't actually apply like it would were it inside the class (or maybe it did and the window just didn't update?) and after closing the window I get this error:
_tkinter.TclError: invalid command name
which I assume is just because it's trying to apply a method to variables that don't exist anymore, now that the window has closed.
So I guess here's my big question - I have a MainWindow class, and from what I can tell, nothing can be changed from outside of the class because the Tk.mainloop() is running and won't stop to let other code after it run, like the itemconfig. How do I go about changing those variables? Code after the instance variable declaration doesn't seem to run until the MainWindow() is closed.
You are correct that code after mainloop doesn't run. It does, but only after the GUI has been destroyed. Tkinter is designed for the call to mainloop be the last (or very nearly last) line of executable code. Once it is called, all other work must be done as reaction to events. That is the essence of GUI programming.
The answer to "how do I go about changing the variables" is simple: do it before you call mainloop, or do it in reaction to an event. For example, do it in a callback to a button, do it in a function bound to an event, or to a time-based event via after, and so on.
I am writing a program using tkinter, but I do not understand how it works. Normally, code is executed top-down, but with tkinter it obviously does not.
For example, I have bound a function to the left mouse button, and this function is executed every time I click the button. But how is the other code around that treated? My problem is that I in the start of my program initialize a variable that is used as an argument in the bound function, and then it is changed in the function and returned. But every time the function is called, the variable seems to be reset to its initial value.
Does anyone know why this is?
I have it written like this:
var = "black"
var = c.bind("<Button-1>", lambda event: func(event, arg=var))
The function "func" changes var and returns it, but the next time I press the button the variable is always "black".
Thanks in advance!
Tkinter does indeed run top down. What makes tkinter different is what happens when it gets to the bottom.
Typically, the last executable statement in a tkinter program is a call to the mainloop method of the root window. Roughtly speaking, tkinter programs look like this:
# top of the program logic
root = tkinter.Tk()
...
def some_function(): ...
...
some_widget.bind("<1>", some_function)
...
# bottom of the program logic
root.mainloop()
mainloop is just a relatively simple infinite loop. You can think of it as having the following structure:
while the_window_has_not_been_destroyed():
event = wait_for_next_event()
process_event(event)
The program is in a constant state of waiting. It waits for an event such as a button click or key click, and then processes that event. Conceptually, it processes the event by scanning a table to find if that event has been associated with the widget that caught the event. If it finds a match, it runs the command that is bound to that widget+event combination.
When you set up a binding or associate a command with a button, you are adding something to that table. You are telling tkinter "if event X happens on widget Y, run function Z".
You can't use a return result because it's not your code that is calling this function. The code that calls the function is mainloop, and it doesn't care what the function returns. Anything that gets returned is simply ignored.
It seems that the object that calls this method waits for the window passed as parameter to be destroyed before continue with its own loop...
From the doc strings of the Misc class, we can observe:
def wait_window(self, window=None):
"""Wait until a WIDGET is destroyed.
If no parameter is given self is used."""
At first glance, it seems like this method can make a Toplevel modal, but this is not true. To make a Toplevel modal, we have to use the grab_set() method.
I have see around other explanations:
wait_window seems to not return until the given widget passed as parameter
is not destroyed.
From another place:
wait_window(widget) - Creates a local event that waits for the given
widget to be destroyed. This loop doesn't affect the application's
mainloop.
From the effbot documentation, we have:
The wait_window enters a local event loop, and doesn’t return until the given window is destroyed (either via the destroy method, or
explicitly via the window manager):
widget.wait_window(window)
What exactly means for a window to wait for window (itself)?
It seems that the code that comes after the call to wait_window is not executed until the window passed to the same method is not destroyed.
In the following working example, we can see a proof on what just said:
from tkinter import *
def on_win_request(parent):
dialog = Toplevel()
parent.wait_window(dialog)
# executed only when "dialog" is destroyed
print("Mini-event loop finished!")
r = Tk()
b = Button(r, text='New Window', command=lambda: on_win_request(r))
b.pack()
b2 = Button(r, text='Hello!', command=lambda: print("hello"))
b2.pack()
r.mainloop()
"Mini-event loop finished!" will be printed only when the local Toplevel widget called dialog is destroyed.
So, in exactly what real circumstances should I use this method?
Like the documentation states, it waits until the given window is destroyed. It is mostly used for modal popups, though it doesn't itself make a window modal. The call to the function simply doesn't return until the target window is destroyed To make a modal window you have to do a grab as well.
The most common use is to create an instance of Toplevel, populate that window with widgets, then wait for the window to be dismissed before doing some other action. While it is waiting, tkinter is able to continue to process events as normal.
For instance, you can disable (or defer creation of) the main GUI, pop up a "terms of service" notice, and wait for the user to acknowledge the terms of service, copyright, license, etc. Once the window is destroyed you can then finish initialization, or enable some widgets, etc.
The standard file dialog is a perfect example: you pop up the dialog, then your code waits for the user to pick a file, then it uses the filename that was returned. Internally, the implementation of the dialog uses wait_window so that it doesn't return until the dialog is dismissed.