Hello I found a little issue with using the turtle library and python's IDLE. Observe the following code written in Python 3.5.2:
import turtle
turtle.Turtle()
input("Try moving/resizing the window in IDLE. Press enter than try again.")
Before pressing enter to give your input, the turtle window will be labeled as unresponsive and not allow the user to resize it. That is, if it's ran with IDLE. However, it works perfectly fine when ran through something such as the windows command prompt or PowerShell.
If ran through IDLE, after the user presses enter the window may then be freely moved and resized with no issues. This comes with the drawback that we're no longer inside the script but back to python's shell. Of course, we can still interact with the turtle via the shell but this isn't what I want in my actual application. My main program uses input() to ask the user if they wish to move/rotate and by how much. This remains in an endless loop until the user enters a phrase such as 'quit' to end the program. I will note, even with IDLE the turtle still moves and is drawn correctly. The problem is that the window itself becomes unresponsive. The contents is all correct.
I'm very curious to as of why only IDLE is giving me such behavior... Not only that, is there a way I can keep turtle window from being unresponsive and still make use of input() and the like? Or perhaps there is an alternative I did not think of? My research has lead me to believe this has something to do with TkInter. That would explain why it only works outside of IDLE.
Below is an image that shows my predicament.
Unresponsive turtle window
As you suspected, the primary issue is with tkinter, not specifically with the turtle app that uses tkinter. I first reproduced in IDLE with a bare tk window.
import tkinter as tk
root = tk.Tk()
input('prompt: ')
I then did the above a line at a time in 3.5.2 running interactively in Command Prompt on Win10. The second line displays a bare window, add a entry in TaskManager, and adds a Python icon to the task bar. Clicking back and forth between CP and Tk causes the the corresponding window and icon to get the 'active' appearance. The window border shifts from gray to black, whereas the icon background shifts from black to gray.
While typing the input statement, but before hitting return, the Tk window shows 'not responding' (after a couple of seconds) both on the title bar and in TaskManager. The mouse over the inside of the window becomes the blue busy circle. The window becomes 'active' as described above, and can be moved, but cannot be resized and cannot be closed normally (clicking on [X] brings up the "Not responding, close or wait?" box.
When the statement is Entered, the tk window becomes normally responsive again. As soon as the 'user' enters anything, the tk window becomes unresponsive in the manner described above, until entry is completed with Enter.
If you retry in CP and enter some characters without hitting Enter, do you see the same unresponsiveness?
Differences in IDLE's shell: creating root puts a new entry in TaskManager, but the new window is attached to the IDLE icon. While the input statement is being written, the Tk window remains normally responsive. So at this stage, IDLE is better. When the input() statement is Entered, the Tk window becomes, as you noted, completely unresponsive (cannot move) even before any entry. This part is worse.
I tried one further experiment: running IDLE with the -n ('no subprocess') option.
C:\Users\Terry>python -m idlelib -n
In this mode, there is no problem that I could detect (unlike CP). This was still true when I ran turtle. You can ignore the deprecation warning for now.
Comment 1: IDLE is designed for development and learning, not for production execution. But it can be used for the latter if there is an advantage to doing so. You would just have to check that using -n does not introduce any other problems, or rather, that turtle and your code do not interfere with IDLE when running in the same process.
Comment 2: GUI programs usually do not use input and print. They are usually run without a console to interact with. If input() is used, even in the Windows console, user should not touch the window before responding to a prompt.
Comment 3: GUI programs usually use GUI widgets instead to fetch and display info. Turtle makes this more difficult, but not impossible, as demonstrated by turtledemo. You might be simplify and adapt the code in turtledemo/main.py.
Related
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)
Is there a way to make a Tkinter window unclickable? Meaning that any input that should be caught by the handler are redirected to whatever window is behind it? If not in Tkinter, would there be a way in PyQt or wxPython? My goal is to have a handler catch keyboard events while still letting them input into the windows behind. I don't need to catch clicks but that would be nice to have if possible.
My current plan:
A Tkinter window with a geometry of 10000x10000, alpha of 0 and topmost set to true. The frame will catch all keyboard & mouse events and when anything is entered the frame will catch it, hide the Tkinter window using an apple script function which is run from terminal with osascript, use autopy to simulate whatever was entered such as a click/keyboard event and unhide the window again. Does this even sound viable?
When I have the time I will test out this idea and post if it works. I'm thinking computation speed will be an issue here.
I have a small GUI application that listens for network messages so a user can update some info and accept it. This is in a production factory environment and used for interacting with a specific piece of physical hardware (over serial in some cases). The workflow looks like this:
User is interacting with another program (5250 Green Screen)
They enter a certain keybinding that sends a UDP message to a Tkinter GUI
The Tkinter GUI does a deiconify()
User edits data, accepts (Enter) and it does an iconify()
My issue is that on windows XP, the GUI does not become active when I do the deiconify and conversely does not fall back to the prior window on iconify. I have tried some things I found in other questions such as:
Setting the Tk GUI as top.. self.wm_attributes("-topmost", 1)
Trying to set/force focus... self.focus_set() and self.focus_force()
Although the window is visible with the first, I can not seem to get it to be the active window so that the user can type in it without "clicking" on it to activate. The same is true for releasing the "focus" so that the active window becomes the one they were previously on (5250).
It seems like an issue that others also have had but I have not been able to find anything that works. Is there a programmatic way to get the window activated and release it when done?
Unfortunately, after a week there have been no answers and I was not able to find a direct way to do this with Tkinter. I did find a way to solve the problem though and it appears to work consistently. Here are the steps I took to make the screens activate:
Install pywin32.
Create a function that activates the tk app.
Create a function that activates the 5250.
Then each time I do a iconify/deiconify I also run the function to activate the appropriate screen. The code that activates the tk window looks like this:
def activate_self(self):
""" Activate this window. """
shell = win32com.client.Dispatch('WScript.Shell')
shell.AppActivate(str(self.title))
shell = None
The code that activates the caller is a little ugly since it has to guess the title but is the same basic concept.
I am trying to follow along in the book Python Programming for Kids. I am working with a group of neighborhood kids and to reduce the cost we are using the Raspberry Pi as our computer. I am a Windows guy and the GUI builder of choice for me is WxPython. I am trying to get ready for next weeks class and have run into a problem. I have entered the code below
from tkinter import *
tk = Tk()
btn = Button(tk,text = 'click me')
btn.pack()
according to the book the second line is supposed to create a window (frame I think in the Wx world) and the third line defines a button object and the fourth inserts it in the window.
However, this is not working and I have not been able to figure out why. tkinter is imported and the tk object has lots of methods/properties visible when I type dir(tk) so I know that we have tkinter on the Pi's.
Any insight would be appreciated.
You have to run the windows system event loop and process events. This means the last command in your program should be tk.mainloop(). The X Windows System operated in a similar manner to Windows. The system dispatches event messages whenever something happens like the mouse moving, a button being clicked or a window needs redrawing and so on. On Windows you would have to 'pump the message queue' using GetMessage() and DispatchMessage(). With Tkinter this is handled in the mainloop() function (for both Windows and X).
Note: This is somewhat a follow-up on the question: Tkinter - when do I need to call mainloop?
Usually when using Tkinter, you call Tk.mainloop to run the event loop and ensure that events are properly processed and windows remain interactive without blocking.
When using Tkinter from within an interactive shell, running the main loop does not seem necessary. Take this example:
>>> import tkinter
>>> t = tkinter.Tk()
A window will appear, and it will not block: You can interact with it, drag it around, and close it.
So, something in the interactive shell does seem to recognize that a window was created and runs the event loop in the background.
Now for the interesting thing. Take the example from above again, but then in the next prompt (without closing the window), enter anything—without actually executing it (i.e. don’t press enter). For example:
>>> t = tkinter.Tk()
>>> print('Not pressing enter now.') # not executing this
If you now try to interact with the Tk window, you will see that it completely blocks. So the event loop which we thought would be running in the background stopped while we were entering a command to the interactive shell. If we send the entered command, you will see that the event loop continues and whatever we did during the blocking will continue to process.
So the big question is: What is this magic that happens in the interactive shell? What runs the main loop when we are not doing it explicitly? And why does it need to halt when we enter commands (instead of halting when we execute them)?
Note: The above works like this in the command line interpreter, not IDLE. As for IDLE, I assume that the GUI won’t actually tell the underlying interpreter that something has been entered but just keep the input locally around until it’s being executed.
It's actually not being an interactive interpreter that matters here, but waiting for input on a TTY. You can get the same behavior from a script like this:
import tkinter
t = tkinter.Tk()
input()
(On Windows, you may have to run the script in pythonw.exe instead of python.exe, but otherwise, you don't have to do anything special.)
So, how does it work? Ultimately, the trick comes down to PyOS_InputHook—the same way the readline module works.
If stdin is a TTY, then, each time it tries to fetch a line with input(), various bits of the code module, the built-in REPL, etc., Python calls any installed PyOS_InputHook instead of just reading from stdin.
It's probably easier to understand what readline does: it tries to select on stdin or similar, looping for each new character of input, or every 0.1 seconds, or every signal.
What Tkinter does is similar. It's more complicated because it has to deal with Windows, but on *nix it's doing something pretty similar to readline. Except that it's calling Tcl_DoOneEvent each time through the loop.
And that's the key. Calling Tcl_DoOneEvent repeatedly is exactly the same thing that mainloop does.
(Threads make everything more complicated, of course, but let's assume you haven't created any background threads. In your real code, if you want to create background threads, you'll just have a thread for all the Tkinter stuff that blocks on mainloop anyway, right?)
So, as long as your Python code is spending most of its time blocked on TTY input (as the interactive interpreter usually is), the Tcl interpreter is chugging along and your GUI is responding. If you make the Python interpreter block on something other than TTY input, the Tcl interpreter is not running and the your GUI is not responding.
What if you wanted to do the same thing manually in pure Python code? You'd of need to do that if you want to, e.g., integrate a Tkinter GUI and a select-based network client into a single-threaded app, right?
That's easy: Drive one loop from the other.
You can select with a timeout of 0.02s (the same timeout the default input hook uses), and call t.dooneevent(Tkinter.DONT_WAIT) each time through the loop.
Or, alternatively, you can let Tk drive by calling mainloop, but use after and friends to make sure you call select often enough.