[Edu-sig] re: new graphics.py etc.

[John Zelle]

Kirby Urner wrote:

>Hi John --
>
>Thank you for sharing your latest graphics.py -- indeed it runs a *lot*
>faster, plus it's nice to have the option of watching screen updates as they
>happen IF you want to.  This is definitely a worthwhile upgrade.
>
>======
>
>Notes:
>
>With WinXP, Python 2.3.3, IDLE 1.0.2:
>
>* no Tk canvas appears, or, if I add a canvas.flush(), a blank one with an
>hour glass cursor appears.  
>  
>
Right. This is a well-known issue. Under IDLE, the graphics program runs 
as a separate process, and does not share the Tkinter mainloop that runs 
in IDLE. When IDLE is waiting for input, the subprocess is "frozen." 
There are a couple of things that you can do to remedy this. One is to 
simply not get input through the IDLE shell window. For example, instead 
for pausing to view graphics output with a raw_input (something that 
requires typing in the shell window), do a win.getMouse() that waits for 
a mouse click. That will keep the Tk window active. The other "fix" is 
to run IDLE with the -n option so that the program is not run as a 
subprocess, but shares IDLE's Tk event loop.

>If I change auto-refresh to True, then I see the canvas being drawn
>properly.  Once it's done, it has the last problem (below)
>
>  
>
Right, since the updates are done on each draw, the window is fully 
drawn before the raw_input in the IDLE shell "freezes" it.

>With WinXP, Python 2.3.3, command window:
>
>* no problems with Tk canvas
>
>With Linux (Mandrake 9.2), Python 2.3.3., IDLE 1.0
>
>* Tk canvas appears, no problem.
>
>Both platforms (with or without IDLE):
>
>I notice that loading both the PIL and graphics.py modules at the same time
>causes problems.  PIL will fail to show anything if graphics.py is loaded
>(same with the older version).  I think this may have to do with both
>modules contending for a Tk root, a problem even when running in shell mode.
>  
>
I was not aware of this problem, I'll have to look into this. Things 
always get a bit funky with multiple modules attempting to use Tk.

>To address the latter problem, I've separated the PIL and graphics.py Canvas
>classes into separate modules (canvas1.py and canvas2.py), so that only one
>or the other library gets used.
>
>  
>
Good workaround for now.

>Both platforms, using IDLE:
>
>if I choose dimensions greater than the screen, or move the Tk canvas off
>the edge, portions of the canvas get wiped and don't refresh. 
>
>  
>
This is actually the same problem as above. When IDLE is paused for 
input, the subprocess freezes, hence you don't get a window repaint. By 
the way, if you are experimenting interactively and have a variable that 
contains the GraphWin, you can always force an update by doing 
win.flush(). That should cause a repaint.

>=====
>
>Note re nks.py
>
>PS:  a more demanding test for nks is t1(30,400,200,3).  That creates a
>3*400 x 3*200 (i.e. 1200x600) canvas.  In general, pixelsize (3) multiplies
>the width (400) and height (200).  Plus height should be half the width,
>given how these particular cellular automata propagate from the center (45
>degree slope).
>
>  
>
>>-----Original Message-----
>>From: edu-sig-bounces at python.org [mailto:edu-sig-bounces at python.org] On
>>Behalf Of John Zelle
>>Sent: Monday, May 10, 2004 8:31 AM
>>To: edu-sig at python.org
>>Subject: Re: [Edu-sig] Re: Teaching graphics withPython (was
>>Introductoryhighschool programming)
>>
>>
>>A number of folks expressed interest, so the newest version of
>>graphics.py is now available on my Python page:
>>http://mcsp.wartburg.edu/zelle/python/graphics.py
>>
>>The only difference between this version and the previous is that it
>>allows the auto-flush of graphics updates to be turned off. This line
>>creates a graphics window w/o immediate automatic updates:
>>
>>myWin = GraphWin("Example Graphics Window", 300, 300, False)
>>
>>The "False" in the last parameter turns off auto-updates. This window
>>will be updated when the Tk event loop is idle or when myWin.flush() is
>>called.  I tested this out with Kirby's nks.py code, and it makes the
>>drawing essentially instantaneous on my machine.
>>
>>I normally do not release tweaks to the graphics package until it has
>>gone through an entire semester of class-use testing, but I am
>>relatively confident that this small change is working. The
>>documentation has not yet been updated. Please let me know if you find
>>any bugs.
>>
>>By the way, for any who are interested in the history of such things,
>>versions of my graphics package before 2.0 (the previous release) always
>>used lazy updating (the auto-flush False behavior). I added the forced
>>updates to version 2.0 to make the package behave better interactively
>>under windows with Idle 1.0 and newer (using subprocesses). The newest
>>version (2.1) now lets you select which mode you want.
>>
>>--John
>>    
>>
>
>
>
>_______________________________________________
>Edu-sig mailing list
>Edu-sig at python.org
>http://mail.python.org/mailman/listinfo/edu-sig
>
>
>  
>