On 3/29/06, Chris <[EMAIL PROTECTED]> wrote:
> ** Regarding turtle speed: when the pen is up, the speed of turtle is
> unbridled.
> ...
> My preference would be to have the motion always obey the
> speed setting--for lines and circles.
+1
I agree. That seems more consistent, and is what I would intuitively expect.
>
> ** Regarding the turtle's rotational speed
>
> When changing the angle of the turtle (like doing motions while the pen
> is up) the change is instantaneous. I find this a little mentally
> jarring. Ease f o r w a r d...TWIST...ease f o r w a r d...TWIST. A
> little gentler approach would do rotations in finite steps. I think the
> "size" of the turtle is 8, so rotating about a maximum of 10 degrees
> per step would be about right, I think. i.e. rotating 90 would be done
> in 9 10-degree steps. Something like this:
>
> def left(self, angle):
> nstep = int(max(1,angle/10.))
> da = float(angle)/nstep
> old = self._angle
> for i in xrange(nstep+1):
> self._angle = (old + da*i) % self._fullcircle
> self._draw_turtle()
> self._canvas.after(self._delay)
> #guard against roundoff
> self._angle = (old + angle) % self._fullcircle
> self._draw_turtle()
>
> But then there is the issue of what to do when the pen is up();
> everything else goes fast right now, perhaps the old left() should be
> used when the pen is up.
>
> [Aside: physically realistic motion really adds a nice touch to
> animations. If you have tried Picasa and scrolled through a list of
> photos you will notice how nice the "feel" is when there is a slight
> acceleration and deceleration when scrolling. This wouldn't be that
> hard to put into the turtle...or Xturtle (I'm not stopping right now to
> see if it's already there, Gregor). For turtle, there is presently only
> one place that the speed controlled motion occurs--in _goto(). To get
> acceleration, you would simply modify the delay times, making them a
> little longer at the beginning and end and shorter in the middle.]
+0
More consistent speed is nice, but is it worth it for this version of
turtle.py?
I would prefer to get a good-enough version of turtle.py out the door,
and then consider a consider a new turtle library, perhaps based on
Gregor's.
> ** Regarding interacting with the turtle in interactive mode with
> PythonWin
>
> A refresh function would be nice so when you cover up the Tk window and
> then come back to your work, you can see what was on the canvas.
> Something as simple as the following would work.
>
> def refresh():
> forward(0)
I am not sure I understand this ... on Linux, when the turtle window
is covered and then put into focus the image is fine with nothing
missing.
>
> ** Regarding the state of the turtle
>
> state changed with learn about with
> ---------- --------------------- -----------------
> position goto, forward, circle position
> heading setheading heading
> drawing up/down ?
> color color ?
> width width ?
> tracing tracer ?
> filling fill ?
> angle unit degrees/radians ?
> speed speed speed()
> delay delay delay(-1)
>
> I think there really should be a way to learn about these other states.
> For example, if you have two people collaborating on a project
> (something I did with groups of students, where each worked on an
> assigned part of the project) and someone wants to use degrees as their
> preferred unit they can do that--but they can't clean up after
> themselves and restore the state which was perhaps in radians. (Well,
> if they wrote a function to rotate the mouse 360 units and then checked
> to see whether the mouse position was about the same then they would
> know they were in degree mode, otherwise radian mode.) The same is true
> for the other states listed above.
>
> If there was an uber-function that returned all the info about the
> window and turtle, that might be good to include, too, in case bugs are
> found in the info returns that are to be provided with the revised
> turtle. That way the inclined users can correct the bugs on their own
> before Python 3000.
Something like this?
>>> turtle.state_info()
{'position': (10, -34), 'heading': 45, units: 'radians'}
> ** regarding how speed and delay return information. I think it would
> be better to use the value None for the default argument, and if the
> argument is None (i.e. nothing was passed in) then the setting should
> be returned. This would make this 'info' use of the function like the
> others like window_width() and heading().
>
> e.g.
>
> def delay(self, delay=None):
> """ sets the drawing delay in milleseconds """
> if delay == None:
> return self._delay
>
> Of course "if not speed" will still work with None instead of '', but
> an actual equivalence test as shown above would have to be used for
> delay since "not 0" is True, but 0 is a valid delay--I know that's why
> -1 was used, but the beauty of None should be used instead.
I don't see the advantage of mixing of setters and getters in this
way. Is this a standard Python idiom? If not, students might start to
write such functions in other code, which doesn't seem advisable.
In a future turtle package, using properties is worth considering, e.g.
>>> turtle.heading
0
>>> turtle.heading = 45
>>> turtle.heading
45
>>> turtle.speed
'slow'
>>> turtle.xy = (100, 75)
>>> turtle.xy
(100, 75)
Toby
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"edupython" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/edupython
-~----------~----~----~----~------~----~------~--~---
