I’m working on a little gui app that will eventually (hopefully) add a watermark to a photo. But right now I’m focused on just messing around with tkinter and trying to get some basic functionality down.
I’ve managed to display an image. Now I want to change the image to whatever is in the Entry widget (ideally, the user would put an absolute path to an image and nothing else). When I click the button, it makes the image disappear. I made it also create a plain text label to see if that would show up. It did.
Okay, time to break out the big guns. Add a breakpoint. py -m pdb main.py
. it works. wtf?
def change_image():
new_image = Image.open(image_path.get()).resize((480, 270))
new_tk_image = ImageTk.PhotoImage(new_image)
test_image_label.configure(image=new_tk_image)
breakpoint()
with the breakpoint, the button that calls change_image works as expected. But without the breakpoint, it just makes the original image disappear. Please help me understand what is happening!
edit: all the code
import io
import tkinter as tk
from pathlib import Path
from tkinter import ttk
from PIL import ImageTk
from PIL import Image
from LocalImage import Localimage
from Layout import Layout
class State:
def __init__(self) -> None:
self.chosen_image_path = ""
def update_image_path(self):
self.chosen_image_path = image_path.get()
def change_image():
new_image = Image.open(image_path.get()).resize((480, 270))
new_tk_image = ImageTk.PhotoImage(new_image)
test_image_label.configure(image=new_tk_image)
breakpoint()
TEST_PHOTO_PATH = "/home/me/bg/space.png"
PIL_TEST_PHOTO_PATH = "/home/me/bg/cyberpunkcity.jpg"
pil_test_img = Image.open(PIL_TEST_PHOTO_PATH).resize((480,270))
# why does the resize method call behave differently when i inline it
# instead of doing pil_test_img.resize() on a separate line?
root = tk.Tk()
root.title("Watermark Me")
mainframe = ttk.Frame(root, padding="3 3 12 12")
mainframe.grid(column=0, row=0, sticky="NWES")
layout = Layout(mainframe)
image_path = tk.StringVar()
tk_image = ImageTk.PhotoImage(pil_test_img)
test_image_label = ttk.Label(image=tk_image)
entry_label = ttk.Label(mainframe, text="Choose an image to watermark:")
image_path_entry = ttk.Entry(mainframe, textvariable=image_path)
select_button = ttk.Button(mainframe, text="Select",
command=change_image)
hide_button = ttk.Button(mainframe, text="Hide", command= lambda x=test_image_label:
layout.hide_image(x))
test_text_label = ttk.Label(mainframe, text="here i am")
empty_label = ttk.Label(mainframe, text="")
for child in mainframe.winfo_children():
child.grid_configure(padx=5, pady=5)
entry_label.grid(column=0, row=0)
image_path_entry.grid(column=1, row=0)
hide_button.grid(column=0, row=3)
select_button.grid(column=0, row=4)
test_image_label.grid(column=0, row=5)
empty_label.grid(column=0, row=6)
image_path_entry.insert(0,TEST_PHOTO_PATH)
image_path_entry.focus()
breakpoint()
root.mainloop()
I’ve used Tkinter in a number of projects, though not the
PIL
specifically. At least not recently?What I have found with Tkinter in general is that it can be rather quirky in terms of dealing with object ownership. I don’t know why this is? You shouldn’t have to worry about tracking object lifetimes in a garbage-collected language like Python, but Tkinter is just…weird about it.
My wager would be that for whatever reason, once your
change_image()
function returns, the garbage collector is coming around and releasingnew_tk_image
(or maybe evennew_image
?), even thoughtest_image_label
should hold a reference to it by that point? And thebreakpoint()
stops the function from returning, so you are “safe” (at least temporarily).What I would try then, as a workaround, would be to store your own references to some of these and see if it works? You can begin by just making them globals to see if this is indeed the problem, though it’s probably more elegant to group them together in a
class
with anything else to do with the window.That was it! I moved the two lines above the
.configure()
call into the outermost scope, and it works now.Should probably just bite the bullet and OOP it out. I was putting that off until I figured out how I wanted the whole thing to work, but it will probably be easier to just do it and change it as I go instead of trying to raw dog it for too long.
Splendid! Glad I was able to help. I know I’ve hit this same problem in some other context? Maybe it was font-handling or something? And it was the same thing. You change the font and it disappears. So I got into the habit of subclassing some higher level object like
Frame
or whatever and making all these things into methods that storeself.current_font
etc. to make sure I don’t let that last reference go bye-bye!
You shouldn’t have to worry about tracking object lifetimes in a garbage-collected language like Python, but Tkinter is just…weird about it.
Don’t know if this is the case with TK, but this is 100% the cause of a lot of bugs working with Qt in python. If you don’t explicitly keep a reference to all your python objects, they can get GCd, and then when the Qt loop tries to access them you get a crash.
Ah so it’s not only Tkinter then. Interesting. Maybe this is one of the reasons why Python-specific GUIs like Kivy came about? When I first started learning Python though, I came under the impression that Tkinter was the “official” Python GUI with privileged status in the standard library, so I started there and was surprised at how it actually doesn’t play all that nice with the language.
Oh well. I’m glad OP brought it up because I’m sure everyone who’s tried to write a GUI in Python for the first time hits this before long and has that same wtf moment. :)
What I have found with Tkinter in general is that it can be rather quirky in terms of dealing with object ownership. I don’t know why this is? You shouldn’t have to worry about tracking object lifetimes in a garbage-collected language like Python, but Tkinter is just…weird about it.
My understanding is very limited, but I think the reason is that TKinter isn’t Python, it’s Tk (i.e., Tcl and/or C). It’s a real thin binding around non-garbage-collected stuff.
This sounds highly plausible. Somehow, Tkinter objects are not always first class Python objects, and the object management (such as it is) is happening outside the scope of Python.
Post the code.
okay, added the rest of the code.