Panda 1.7 + TKinter: freeze after losing focus

Since upgrading to Panda 1.7, a certain TKinter window hangs itself and the main Panda window whenever it loses focus to another application.

a) I run a Panda app
b) I open a TKinter window, running in a separate Python thread
c) I can move the TK window around as much as I like
d) I click on another window such as the command prompt or even the main Panda window. Clicking on the textarea also causes the same behaviour.
e) I can’t switch back to the TK window because it is all frozen, and requires a forced quit using the Task Manager

The code for the TK window is here:

class TkCodeEditor(threading.Thread):

    def __init__(self, aMaster, aCodeBlockID, resultObj):

        # build frame
        self.Master = aMaster
        self.Master.title('Editing "' + get_block_name(aCodeBlockID) + '"')
        self.CodeBlockID = aCodeBlockID
        self.resultObj = resultObj
        self.startHash = hashlib.md5()

        EditFrame = Frame(self.Master)
        EditFrame.pack(side=LEFT, fill=BOTH, expand=True)

        # build code text
        TextFrame = Frame(EditFrame)
        self.CodeText = Text(TextFrame)
        scroll = Scrollbar(TextFrame)
        scroll['command'] = self.CodeText.yview               # allows scroll bar to move text
        self.CodeText.configure(yscrollcommand=scroll.set)    # allows text to move scrollbar
        self.CodeText.insert(END, get_code(self.CodeBlockID))
        self.CodeText.config(undo=1)    # this is after the .insert() so user doesn't accidentally erase everything
        self.CodeText.pack(anchor=NW, side=LEFT, fill=BOTH, expand=True)
        scroll.pack(anchor=NE, side=RIGHT, fill=Y, expand=True)
        TextFrame.pack(side=TOP, fill=BOTH, expand=True)

        ButtonFrame = Frame(EditFrame)
        ButtonFrame.pack(anchor=SE, side=BOTTOM, fill=X, expand=True)

        self.CancelButton = Button(ButtonFrame, text='Cancel', fg='black', command=self._cancel)

        self.SaveNewButton = Button(ButtonFrame, text='Save New', command=self._save_new)

        self.SaveButton = Button(ButtonFrame, text='Save', command=self._save)
        if get_code_id(aCodeBlockID) == 1:

        self.Master.bind('<Escape>', self._escape)


    def run(self):

    def _get_text(self):
        nowText = self.CodeText.get(1.0, END)
        nowText = nowText[:len(nowText) - 1]
        return nowText

    def _save(self):
        set_code(self.CodeBlockID, self._get_text())
        self.resultObj.pleaseRedraw = True

    def _save_new(self):
	# irrelevant detail

    def _has_changed(self):
        self.nowHash = hashlib.md5()
        return self.nowHash.digest() != self.startHash.digest()    # i.e. user has changed something

    def _escape(self, event=None):
        if not self._has_changed():

    def _cancel(self):

It is called with these lines:

TKRoot = Tk()
editor = TkCodeEditor(TKRoot, CodeBlockID, self)

What is the last version of Panda3D in which this worked?

I’m not sure what the problem is, though using Python threads in conjunction with Panda3D code can be problematic. I can’t say that this is definitely your problem, but it’s a possibility. Is there an option to use a polling system instead of calling mainloop()? This is the way we implement the default Tk event loop in Direct, when want-tk is enabled in the Config.prc file (see base.startTk(), and TkLoop).


The last version it worked in is 1.6.2. This is one of three bugs that 1.7 introduced, but I need the multithreading module from Python 2.6 so I don’t want to downgrade.

The funny thing is that other custom Tk windows in my app work fine, for instance input dialogs with an Entry field, and Yes/No buttons. This code-editing dialog is really no more complicated than those aside from an extra textarea field. It makes me wonder whether the python threading is really the culprit.

Idk about polling the Tk GUI, but I’ll look into it.


Okay, not sure I’ve made any progress with finding anything about TK polling.

I ran a version of my code from a couple weeks ago, and it works (i.e. nothing freezes). The problem is that it isn’t in a separate thread so the main Panda window blacks out. I take this to mean 1.7 isn’t the problem; so maybe TK 8.5.

I don’t care how it’s implemented in the end; something other than TK is fine. Any more suggestions?

If you’re not wedded to Tk, have you considered using wxPython? We have already been in the process of gradually migrating the standard Panda dialogs from Tk to wx.


I’ll give it a go. Thanks.

I changed my PATH variable to use 1.6.2 again, and things are back to normal. Something weird is going on in 1.7.0, methings :slight_smile:

A couple other mysterious bugs also have disappeared since the downgrade.

Just a suggestion: maybe make it more obvious that 1.7.0 is not the latest stable code on the download page. Putting 1.6.2 above 1.7.0 would make a lot more sense than hiding it way past the scroll point. Personally I saw the “unstable” word beside 1.7, but thought that since such a big deal was made of it - top of page, big font, in-your-face link - it was decently tested lol


Hum, I think in general, 1.7.0 is better than 1.6.2; but it’s true there are some bugs that are new to 1.7.0.

I think the better answer will be to get these fixed and 1.7.1 released soon. But progress on that is slow.


I’d be interested to know whether there is any work on 1.7 that I could do. I am aware of the bug tracker, but my C++ knowledge is limited to one undergrad course. Maybe some documentation needs to be written/rewritten, or coding conventions checked in some files?

There’s certainly plenty of work to be done. The manual is a wiki and can be edited by anyone with enough interest to search the forums and find the login link. :slight_smile: We’d love to have some of the weaker sections shored up a bit.

Similarly, the in-code comments are sometimes weak (and these comments are used to generate the reference API, so it’s useful to have them improved). Fixing these requires getting cvs access, or at least submitting patches, but it is still welcome work.

Retrofitting coding conventions is also a fine idea, one I haven’t really considered asking volunteers to do before–but it makes a lot of sense, because you can do it without necessarily having strong C++ experience, and doing it may help increase your understanding of Panda as well. There are indeed several parts of the code that fail to live up to our declared formatting standards. Is this the sort of thing you’d be interested in improving?


Sounds good. I don’t trust myself to change anything that users (aka “the public”) will see, which includes the manual and docstrings. I’d be glad to put some time into the other things, though, and at least see how it goes.

I was introduced to Panda this summer, and it’s making me want to put a 3D GUI on every program I write - so many possibilities lol. Hopefully any work on Panda I do will gradually make life easier for me as well as you.