Re: [Edu-sig] Any suggestions about turlte.py
Hi, Thank you for taking care of the turtle.py module. Here are tow suggestions. [1] I would suggest a correction of a bug in the fill function of turtle.py. The statement: # self._canvas.lower(item) should be removed. As it is now, it lowers polygons when filled. This causes inconsistent behavior because nothing else is lowered. Here is a suggested the statement in context: def fill(self, flag): if self._filling: path = tuple(self._path) smooth = self._filling < 0 if len(path) > 2: item = self._canvas._create('polygon', path, {'fill': self._color, 'smooth': smooth}) self._items.append(item) # Should be removed, because # nothing else is lowered but filled polygons: # self._canvas.lower(item) if self._tofill: for item in self._tofill: self._canvas.itemconfigure(item, fill=self._color) self._items.append(item) self._path = [] self._tofill = [] self._filling = flag if flag: self._path.append(self._position) self.forward(0) [2] A nuisance with this otherwise quite useful module is its behavior in Windows systems: It tends to *stop responding*. This happens when the canvas is covered by other graphics for a while, especially in cases when execution is triggered form the interactive prompt. It would be great if this problem can be fixed (although I am not sure what can be done about it.) Atanas Atanas Radenski mailto:radenski@chapman.edu http://www.chapman.edu/~radenski/ I find television very educating. Every time somebody turns on the set, I go into the other room and read a book - Groucho Marx
-----Original Message----- From: edu-sig-bounces@python.org [mailto:edu-sig-bounces@python.org] On Behalf Of Vern Ceder Sent: Monday, February 27, 2006 11:32 AM To: Edu-sig@python.org Subject: [Edu-sig] Any suggestions about turlte.py
Hello everyone,
As a consequence of my complaining about it in my PyCon talk, I have been invited to submit some patches for turtle.py. To my mind, turtle.py should be something that one could actually use for some very simple "programming with graphics" lessons, with NO tweaking or additional software.
So I think the following would be handy:
1. equally usable with either "import * from turtle" or "import turtle" imports 2. should open with a window covering at least half the screen (the current default is too small to be useful) 3. should offer some simple configuration choices for things like initial size and shape, but mostly rely on reasonable defaults 4. should offer a class wrapper so that that one could easily instantiate different turtles for a first experience with objects. 5. some minor tweaks to make it better behaved when run from IDLE
Does anyone have any feedback on these ideas or any other suggestions about how turtle.py might be improved without being fundamentally changed?
Note: this is about turtle.py only, for all its deficiencies. Any suggestions to try another library, system, or language will be cheerfully, but resolutely, ignored. ;)
Cheers, Vern Ceder
-- This time for sure! -Bullwinkle J. Moose ----------------------------- Vern Ceder, Director of Technology Canterbury School, 3210 Smith Road, Ft Wayne, IN 46804 vceder@canterburyschool.org; 260-436-0746; FAX: 260-436-5137 _______________________________________________ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Atanas, Thanks for the input - I wasn't aware of the first problem you mention. I'm not sure about the secnond issue - do you mean that a turtle program that is *running* will hang if covered by other graphics? Or that a window with an already completed drawing/program will become unrresponsive? I've seen the second behavior, but not the first. Thanks, Vern Radenski, Atanas wrote:
Hi,
Thank you for taking care of the turtle.py module. Here are tow suggestions.
[1] I would suggest a correction of a bug in the fill function of turtle.py. The statement:
# self._canvas.lower(item)
should be removed. As it is now, it lowers polygons when filled. This causes inconsistent behavior because nothing else is lowered. Here is a suggested the statement in context:
def fill(self, flag): if self._filling: path = tuple(self._path) smooth = self._filling < 0 if len(path) > 2: item = self._canvas._create('polygon', path, {'fill': self._color, 'smooth': smooth}) self._items.append(item)
# Should be removed, because # nothing else is lowered but filled polygons:
# self._canvas.lower(item)
if self._tofill: for item in self._tofill: self._canvas.itemconfigure(item, fill=self._color) self._items.append(item) self._path = [] self._tofill = [] self._filling = flag if flag: self._path.append(self._position) self.forward(0)
[2] A nuisance with this otherwise quite useful module is its behavior in Windows systems: It tends to *stop responding*. This happens when the canvas is covered by other graphics for a while, especially in cases when execution is triggered form the interactive prompt. It would be great if this problem can be fixed (although I am not sure what can be done about it.)
Atanas
Atanas Radenski mailto:radenski@chapman.edu http://www.chapman.edu/~radenski/
I find television very educating. Every time somebody turns on the set, I go into the other room and read a book - Groucho Marx
-----Original Message----- From: edu-sig-bounces@python.org [mailto:edu-sig-bounces@python.org]
On
Behalf Of Vern Ceder Sent: Monday, February 27, 2006 11:32 AM To: Edu-sig@python.org Subject: [Edu-sig] Any suggestions about turlte.py
Hello everyone,
As a consequence of my complaining about it in my PyCon talk, I have been invited to submit some patches for turtle.py. To my mind,
turtle.py
should be something that one could actually use for some very simple "programming with graphics" lessons, with NO tweaking or additional software.
So I think the following would be handy:
1. equally usable with either "import * from turtle" or "import
turtle"
imports 2. should open with a window covering at least half the screen (the current default is too small to be useful) 3. should offer some simple configuration choices for things like initial size and shape, but mostly rely on reasonable defaults 4. should offer a class wrapper so that that one could easily instantiate different turtles for a first experience with objects. 5. some minor tweaks to make it better behaved when run from IDLE
Does anyone have any feedback on these ideas or any other suggestions about how turtle.py might be improved without being fundamentally
changed?
Note: this is about turtle.py only, for all its deficiencies. Any suggestions to try another library, system, or language will be cheerfully, but resolutely, ignored. ;)
Cheers, Vern Ceder
-- This time for sure! -Bullwinkle J. Moose ----------------------------- Vern Ceder, Director of Technology Canterbury School, 3210 Smith Road, Ft Wayne, IN 46804 vceder@canterburyschool.org; 260-436-0746; FAX: 260-436-5137 _______________________________________________ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
-- This time for sure! -Bullwinkle J. Moose ----------------------------- Vern Ceder, Director of Technology Canterbury School, 3210 Smith Road, Ft Wayne, IN 46804 vceder@canterburyschool.org; 260-436-0746; FAX: 260-436-5137
participants (2)
-
Radenski, Atanas -
Vern Ceder