Re: [Edu-sig] How to explore Tkinter interactively with IDLE 1.0
Kirby Urner schrieb:
Hi Gregor --
Shortly, learn how Tkinter works
2. Using turtle-graphics
from turtle import * forward(100)
I'm able to accomplish the following without trouble:
Hi Kirby, this definitely doesn't work on my machine (Windows XP with Python 3.2) after having typed up() the turtle window is created, but it remains behind the IDLE window. I click the corresponting taskbar-button, see the turtle-window and after a few seconds there appears the message "keine ruecklmeldung" (something like "no response") in the title-bar of the turtle window. I cant't draw in that window - but, yes, i can close it with shell-restart. What's going on? Gregor
from turtle import * up() setx(0) forward(100) down() right(180) forward(200) ============== RESTART ==============
This last line shows how I close the turtle window, by going up to 'shell' and clicking on 'restart shell'. I can't find any more graceful way to exit.
A Canvas pops up and the turtle starts to move and remains ready for the user to interact with her interactively.
Alas! Both examples don't work in ordinary IDLE 1.0 - mode I'm well aware of the advantages of IDLE 1.0, especially the one always to have a clean workspace for testing programs - and I'd like to port as much of them to a customized development environment I use in my classes.
I am using:
Python 2.3.1 (#47, Sep 23 2003, 23:47:32) [MSC v.1200 32 bit (Intel)] on win32 Type "copyright", "credits" or "license()" for more information.
**************************************************************** Personal firewall software may warn about the connection IDLE makes to its subprocess using this computer's internal loopback interface. This connection is not visible on any external interface and no data is sent to or received from the Internet. ****************************************************************
IDLE 1.0
Re font size, custom colors etc., yes, I believe it, those things do matter.
Kirby
Hi Kirby, this definitely doesn't work on my machine (Windows XP with Python 3.2)
I just downloaded 2.3.1 today or yesterday. That couldn't be the difference could it? Windows XP here too. It's true for me as well that when I first say up(), the Tk window is behind the main one. I see it by sliding the main one out of the way. I don't touch the secondary one. The secondary window (showing the turtle) is not responsive in the usual way. For example, if I hit the maximize icon, nothing happens. But next time I go up(), the window maximizes (i.e. the action occurs only on programmatic refresh). Likewise to shrink it down again (using the icon) -- the resize event is postponed until the next turtle event. If the secondary window minimizes to the task bar, I double-click on it. Then I go up() or setx() or something, and it tends to return to its previous (open) state. If a window moves in front of the secondary window, and then is moved away, the secondary window will not refresh and is likely blank -- until the next turtle event. Kirby
On Thursday, September 25, 2003, at 10:09 PM, Kirby Urner wrote:
It's true for me as well that when I first say up(), the Tk window is behind the main one. I see it by sliding the main one out of the way. I don't touch the secondary one.
The secondary window (showing the turtle) is not responsive in the usual way.
This is the case for me when I try using turtle commands from the python interpreter interactively, so it doesn't seem to be limited to Idle behaviour. I'm using Python 2.3 on OS X (10.2) with the native Tk library. I cannot close the Tk window. When I click in the window the interpreter prints
SetFrontProcess failed,-606
And the window has none of the control buttons or drag bar enabled. OS X has some issues normally with starting up GUI windows from the command-line, but you can generally interact with them. I hadn't played with the turtle package (I should look at it, since I've written my own incomplete turtle program with totally different interaction). This was fun: def zap(x): for i in range(0, x * 5, 5): circle(i) for x in range(8): right(60) zap(x + 5) It needs sound effects, though. --Dethe
Dethe Elza schrieb:
On Thursday, September 25, 2003, at 10:09 PM, Kirby Urner wrote:
It's true for me as well that when I first say up(), the Tk window is behind the main one. I see it by sliding the main one out of the way. I don't touch the secondary one.
The secondary window (showing the turtle) is not responsive in the usual way.
This is the case for me when I try using turtle commands from the python interpreter interactively, so it doesn't seem to be limited to Idle behaviour. I'm using Python 2.3 on OS X (10.2) with the native Tk library. I cannot close the Tk window. When I click in the window the interpreter prints
SetFrontProcess failed,-606
Hi Dethe, this doesn't occur under Windows. With commandline-python works as expected. Moreover the Tk - example from my prior posting works also with Python 3.2.1 command line interpreter exactly as it did with IDLE 0.8 in earlier Python versions. Regards, Gregor
And the window has none of the control buttons or drag bar enabled. OS X has some issues normally with starting up GUI windows from the command-line, but you can generally interact with them.
I hadn't played with the turtle package (I should look at it, since I've written my own incomplete turtle program with totally different interaction). This was fun:
def zap(x): for i in range(0, x * 5, 5): circle(i)
for x in range(8): right(60) zap(x + 5)
It needs sound effects, though.
--Dethe
_______________________________________________ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Hello all, I just wanted to confirm what has been reported here regarding IDLE 1.0. I have a simple 2D graphics package that I developed for CS1. It is basically a thin wrapper over a TK canvas. With versions of IDLE prior to 1.0, it was easy to experiment with the graphics interactively. Now, that is much harder. The basic problem is that the eventloop in the subprocess window is suspended when the IDLE interactive shell is waiting for input. As has already been reported, judicious calling of update() can be used to force the window to flush its queue. You can call update() from the IDLE shell to force the window to react. For example:
from Tkinter import * win = Tk() # nothing appears win.update() # Tk window pops up # now click in the close box of the Tk window, nothing happens win.update() # Tk window closes
The interesting thing is that events are getting posted even when the window is unresponsive. As this example shows, the click in the close box is carried out when the update() call is made. Under Windows, subprocess Tk windows are completely unresponsive and often pop up underneath the IDLE window. If you drag the Tk window with the mouse, nothing seems to happen, but typing win.update() in the shell will cause the Tk window to jump to the new location. Under Linux, the situation is slightly better, the window is still under control of the window manager and can be moved and resized, but Tk events do not occur until an update(). My partial solution to this problem has been to add updates() to my library. But realistically, if you want to do interactive experiementation with Tkinter, the DOS or Linux command line is the better route now. It would be nice if this could be fixed, but I'm willing to give this up for the other features introduced by the IDLE fork. --John Gregor Lingl wrote:
Dethe Elza schrieb:
On Thursday, September 25, 2003, at 10:09 PM, Kirby Urner wrote:
It's true for me as well that when I first say up(), the Tk window is behind the main one. I see it by sliding the main one out of the way. I don't touch the secondary one.
The secondary window (showing the turtle) is not responsive in the usual way.
This is the case for me when I try using turtle commands from the python interpreter interactively, so it doesn't seem to be limited to Idle behaviour. I'm using Python 2.3 on OS X (10.2) with the native Tk library. I cannot close the Tk window. When I click in the window the interpreter prints
SetFrontProcess failed,-606
Hi Dethe, this doesn't occur under Windows. With commandline-python works as expected.
Moreover the Tk - example from my prior posting works also with Python 3.2.1 command line interpreter exactly as it did with IDLE 0.8 in earlier Python versions.
Regards, Gregor
And the window has none of the control buttons or drag bar enabled. OS X has some issues normally with starting up GUI windows from the command-line, but you can generally interact with them.
I hadn't played with the turtle package (I should look at it, since I've written my own incomplete turtle program with totally different interaction). This was fun:
def zap(x): for i in range(0, x * 5, 5): circle(i)
for x in range(8): right(60) zap(x + 5)
It needs sound effects, though.
--Dethe
_______________________________________________ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
_______________________________________________ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
-- John M. Zelle, Ph.D. | Wartburg College Associate Prof. of CS | Dept. Math/CS/Physics john.zelle@wartburg.edu | Waverly, Iowa
I just wanted to confirm what has been reported here regarding IDLE 1.0. I have a simple 2D graphics package that I developed for CS1. It is basically a thin wrapper over a TK canvas. With versions of IDLE prior to 1.0, it was easy to experiment with the graphics interactively. Now, that is much harder. The basic problem is that the eventloop in the subprocess window is suspended when the IDLE interactive shell is waiting for input. As has already been reported, judicious calling of update() can be used to force the window to flush its queue. You can call update() from the IDLE shell to force the window to react.
For example:
from Tkinter import * win = Tk() # nothing appears win.update() # Tk window pops up # now click in the close box of the Tk window, nothing happens win.update() # Tk window closes
The interesting thing is that events are getting posted even when the window is unresponsive. As this example shows, the click in the close box is carried out when the update() call is made.
Under Windows, subprocess Tk windows are completely unresponsive and often pop up underneath the IDLE window. If you drag the Tk window with the mouse, nothing seems to happen, but typing win.update() in the shell will cause the Tk window to jump to the new location. Under Linux, the situation is slightly better, the window is still under control of the window manager and can be moved and resized, but Tk events do not occur until an update().
My partial solution to this problem has been to add updates() to my library. But realistically, if you want to do interactive experiementation with Tkinter, the DOS or Linux command line is the better route now. It would be nice if this could be fixed, but I'm willing to give this up for the other features introduced by the IDLE fork.
This is because under IDLE 1.0, Tkinter programs don't get to benefit from IDLE's Tkinter mainloop. Tkinter programs written for use outside IDLE runs fine under the new IDLE, because such programs already have an explicit call to the Tkinter mainloop (otherwise they wouldn't function at all). Under IDLE 0.8, such programs, once started, would be hard to stop because their mainloop and IDLE's mainloop would compete. But interactively playing with Tkinter has become harder. So, the new IDLE, conforming one of its design goals, has actually become more compatible with Tkinter applications -- but at the same time the unique IDLE 0.8 feature of easy interactive Tkinter experimentation has gone out of the window. A work-around is to use the -n command line argument to idle (a bit tricky to invoke on Windows but you should be able to add this to the IDLE alias or create a batch file for it), which runs the Python code in the IDLE process as in IDLE 0.8 (with all the risks of that mode, like losing data in IDLE when the app crashes or hangs). Perhaps this could be made a more easily configurable option (a checkbox or radio button in the General configurations dialog would seem the right place). Do we need something else? Perhaps some trick that you can invoke that runs a Tkinter mainloop in a background thread? (But note that Tkinter and threads don't go well together.) --Guido van Rossum (home page: http://www.python.org/~guido/)
Guido van Rossum schrieb:
This is because under IDLE 1.0, Tkinter programs don't get to benefit from IDLE's Tkinter mainloop. Tkinter programs written for use outside IDLE runs fine under the new IDLE, because such programs already have an explicit call to the Tkinter mainloop (otherwise they wouldn't function at all). Under IDLE 0.8, such programs, once started, would be hard to stop because their mainloop and IDLE's mainloop would compete. But interactively playing with Tkinter has become harder.
So, the new IDLE, conforming one of its design goals, has actually become more compatible with Tkinter applications -- but at the same time the unique IDLE 0.8 feature of easy interactive Tkinter experimentation has gone out of the window.
A work-around is to use the -n command line argument to idle (a bit tricky to invoke on Windows but you should be able to add this to the IDLE alias or create a batch file for it), which runs the Python code in the IDLE process as in IDLE 0.8 (with all the risks of that mode, like losing data in IDLE when the app crashes or hangs).
Hi Guido, thanks for your reply. For experimentation with Tkinter I do use IDLE with the -n switch in my classes.
Perhaps this could be made a more easily configurable option (a checkbox or radio button in the General configurations dialog would seem the right place).
The dream of any teacher would be, of course, to have a menu-switch to flip between the two modes without the need to restart IDLE. But probably this would be hard to implement.
Do we need something else? Perhaps some trick that you can invoke that runs a Tkinter mainloop in a background thread? (But note that Tkinter and threads don't go well together.)
Doesn't Tkinter claim to be threadsafe? (The few simple programs I wrote, whith several threads drawing on the same Canvas showed no problems.) However there is a different point: In my classes I use the -Qnew switch for the Python interpreter (and also in my book, as you already noticed, when you read some excerpts of it) and this works fine with IDLE -n, but, alas, it doesn't work with IDLE 1.0 in standard mode. Is this a feature or a bug? So what about a switch - or at least also a configuration option - for the new division? Regards, Gregor
--Guido van Rossum (home page: http://www.python.org/~guido/)
_______________________________________________ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Doesn't Tkinter claim to be threadsafe? (The few simple programs I wrote, whith several threads drawing on the same Canvas showed no problems.)
It does claim so, but (esp. on Windows) I'm doubtful of that claim for large apps.
However there is a different point: In my classes I use the -Qnew switch for the Python interpreter (and also in my book, as you already noticed, when you read some excerpts of it) and this works fine with IDLE -n, but, alas, it doesn't work with IDLE 1.0 in standard mode. Is this a feature or a bug?
I consider it a bug. I'm not sure how easy it will be to fix though, but I encourage you to submit a SF bug for this.
So what about a switch - or at least also a configuration option - for the new division?
A config option could work but only if you don't use -n. :-) --Guido van Rossum (home page: http://www.python.org/~guido/)
[resend, I wanted this to go to idle-dev but typed idle-sig]
I just wanted to confirm what has been reported here regarding IDLE 1.0. I have a simple 2D graphics package that I developed for CS1. It is basically a thin wrapper over a TK canvas. With versions of IDLE prior to 1.0, it was easy to experiment with the graphics interactively. Now, that is much harder. The basic problem is that the eventloop in the subprocess window is suspended when the IDLE interactive shell is waiting for input. As has already been reported, judicious calling of update() can be used to force the window to flush its queue. You can call update() from the IDLE shell to force the window to react.
For example:
from Tkinter import * win = Tk() # nothing appears win.update() # Tk window pops up # now click in the close box of the Tk window, nothing happens win.update() # Tk window closes
The interesting thing is that events are getting posted even when the window is unresponsive. As this example shows, the click in the close box is carried out when the update() call is made.
Under Windows, subprocess Tk windows are completely unresponsive and often pop up underneath the IDLE window. If you drag the Tk window with the mouse, nothing seems to happen, but typing win.update() in the shell will cause the Tk window to jump to the new location. Under Linux, the situation is slightly better, the window is still under control of the window manager and can be moved and resized, but Tk events do not occur until an update().
My partial solution to this problem has been to add updates() to my library. But realistically, if you want to do interactive experiementation with Tkinter, the DOS or Linux command line is the better route now. It would be nice if this could be fixed, but I'm willing to give this up for the other features introduced by the IDLE fork.
This is because under IDLE 1.0, Tkinter programs don't get to benefit from IDLE's Tkinter mainloop. Tkinter programs written for use outside IDLE runs fine under the new IDLE, because such programs already have an explicit call to the Tkinter mainloop (otherwise they wouldn't function at all). Under IDLE 0.8, such programs, once started, would be hard to stop because their mainloop and IDLE's mainloop would compete. But interactively playing with Tkinter has become harder. So, the new IDLE, conforming one of its design goals, has actually become more compatible with Tkinter applications -- but at the same time the unique IDLE 0.8 feature of easy interactive Tkinter experimentation has gone out of the window. A work-around is to use the -n command line argument to idle (a bit tricky to invoke on Windows but you should be able to add this to the IDLE alias or create a batch file for it), which runs the Python code in the IDLE process as in IDLE 0.8 (with all the risks of that mode, like losing data in IDLE when the app crashes or hangs). Perhaps this could be made a more easily configurable option (a checkbox or radio button in the General configurations dialog would seem the right place). Do we need something else? Perhaps some trick that you can invoke that runs a Tkinter mainloop in a background thread? (But note that Tkinter and threads don't go well together.) --Guido van Rossum (home page: http://www.python.org/~guido/)
participants (5)
-
Dethe Elza -
Gregor Lingl -
Guido van Rossum -
John Zelle -
Kirby Urner