Fwd: etoys bug?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Fwd: etoys bug?

Bert Freudenberg
Begin forwarded message:

> Hi,
>
> The Squeakland contact page was reluctant to let me message about this problem so I'm spamming you.  Sorry.

Seems the form is broken, sorry. I filed a bug report. However, the mailing list is a better place to ask anyway.

> The visibility of a scriptor seems to affect how things work.  Here's a link to a page with a more clear description of the problem and a simplified project which exhibits the bad behavior.  (Apologies again...our email filters wouldn't let me send the project as an attachment...hopefully you can grab it from the webpage)
>
> http://krypton.mnsu.edu/~kelled/public/etoys/prob_info.html

I am forwarding this mail of yours to our mailing list. Please subscribe here to receive the answers:

        http://squeakland.org/discuss/squeakland/

- Bert -

> Regards,
> dk
>
>
> --------------------------------------------------------------------------------
> Dean Kelley, PhD
> Associate Professor of Computer Science
> Department of Integrated Engineering, MSU
> Mankato, MN  56001

_______________________________________________
squeakland mailing list
[hidden email]
http://lists.squeakland.org/mailman/listinfo/squeakland
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: etoys bug?

dcorking
Dean Kelley wrote:

>> The visibility of a scriptor seems to affect how things work. )
>>
>> http://krypton.mnsu.edu/~kelled/public/etoys/prob_info.html

Without getting into the Smalltalk code, I seem to have narrowed down
the bug a little more.

It seems that the effect appears as you intended whenever the
rectangle is overlapped by the basepf doflash script editor, or the
basepf viewer. (There is no need to hide the script editor to cause
the bug to be exhibited: merely move it so it no longer overlaps the
rectangle.)

As a workaround it seems you can move basepf to the right, up or down
by 1 pixel, or more, though not to the left. Then the effect works,
even when the script is hidden.

I hope those are a few clues that help someone else figure out what is
going on deeper inside Etoys. (I used Etoys 5.0 build 2406 on Mac OS
X.)

Have fun! David
_______________________________________________
squeakland mailing list
[hidden email]
http://lists.squeakland.org/mailman/listinfo/squeakland
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: etoys bug?

Steve Thomas
Dean, 

Not sure if you joined the mailing list so you may not have seen David's observations below.
I have one other additional observation that also resolves the issue:

Simply remove the show/hide scripting files for basepf and flashpf.  You may also want to bring blackpf to front (using the menu icon in the halo).

Looking at your web page it seems you taught a summer workshop for Elementary School Teachers, so you are probably familiar with the Etoys Illinois site

Would love to hear more about how you are using Etoys in the classroom.

Cheers,
Stephen

I want to know if I am wrong, because I want to be right. So if I'm wrong lets find out.
    - Margeret Heffernan

On Tue, Jul 9, 2013 at 5:33 PM, David Corking <[hidden email]> wrote:
Dean Kelley wrote:

>> The visibility of a scriptor seems to affect how things work. )
>>
>> http://krypton.mnsu.edu/~kelled/public/etoys/prob_info.html

Without getting into the Smalltalk code, I seem to have narrowed down
the bug a little more.

It seems that the effect appears as you intended whenever the
rectangle is overlapped by the basepf doflash script editor, or the
basepf viewer. (There is no need to hide the script editor to cause
the bug to be exhibited: merely move it so it no longer overlaps the
rectangle.)

As a workaround it seems you can move basepf to the right, up or down
by 1 pixel, or more, though not to the left. Then the effect works,
even when the script is hidden.

I hope those are a few clues that help someone else figure out what is
going on deeper inside Etoys. (I used Etoys 5.0 build 2406 on Mac OS
X.)

Have fun! David
_______________________________________________
squeakland mailing list
[hidden email]
http://lists.squeakland.org/mailman/listinfo/squeakland


_______________________________________________
squeakland mailing list
[hidden email]
http://lists.squeakland.org/mailman/listinfo/squeakland
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: etoys bug?

Kelley, Dean F
Thanks, Steve.  I think I isolated the problem a bit more with a simpler project (description and link to project at http://krypton.mnsu.edu/~kelled/public/etoys/prob_info.html ...see the "Update 2.5" part)


The workshop for elementary teachers was very *VERY* far outside my comfort zone.  I enjoyed it immensely.

My impression was that Etoys is largely unknown among education majors, especially elementary education majors.  At least locally.  (I was right.)   So my intent was to expose people to Etoys and how it has been used by others while at the same time trying to provide enough hands-on experience that people would feel comfortable enough with Etoys to be inclined to try to incorporate it into their teaching.  We looked at some projects, worked through some tutorial material that Avigail Snir gave me and then did individual projects.  It will definitely be repeated.


Thanks again,
dk

--------------------------------------------------------------------------------
Dean Kelley, PhD
Associate Professor of Computer Science
Department of Integrated Engineering, MSU
Mankato, MN  56001
________________________________________
From: [hidden email] [[hidden email]] on behalf of Steve Thomas [[hidden email]]
Sent: Tuesday, July 09, 2013 10:34 PM
To: Kelley, Dean F
Cc: squeakland list; David Corking
Subject: Re: [squeakland] Fwd: etoys bug?

Dean,

Not sure if you joined the mailing list so you may not have seen David's observations below.
I have one other additional observation that also resolves the issue:

Simply remove the show/hide scripting files for basepf and flashpf.  You may also want to bring blackpf to front (using the menu icon in the halo).

Looking at your web page it seems you taught a summer workshop for Elementary School Teachers, so you are probably familiar with the Etoys Illinois site<http://etoysillinois.org>

<http://etoysillinois.org>Would love to hear more about how you are using Etoys in the classroom.

Cheers,
Stephen

I want to know if I am wrong, because I want to be right. So if I'm wrong lets find out.
    - Margeret Heffernan

On Tue, Jul 9, 2013 at 5:33 PM, David Corking <[hidden email]<mailto:[hidden email]>> wrote:
Dean Kelley wrote:

>> The visibility of a scriptor seems to affect how things work. )
>>
>> http://krypton.mnsu.edu/~kelled/public/etoys/prob_info.html

Without getting into the Smalltalk code, I seem to have narrowed down
the bug a little more.

It seems that the effect appears as you intended whenever the
rectangle is overlapped by the basepf doflash script editor, or the
basepf viewer. (There is no need to hide the script editor to cause
the bug to be exhibited: merely move it so it no longer overlaps the
rectangle.)

As a workaround it seems you can move basepf to the right, up or down
by 1 pixel, or more, though not to the left. Then the effect works,
even when the script is hidden.

I hope those are a few clues that help someone else figure out what is
going on deeper inside Etoys. (I used Etoys 5.0 build 2406 on Mac OS
X.)

Have fun! David
_______________________________________________
squeakland mailing list
[hidden email]<mailto:[hidden email]>
http://lists.squeakland.org/mailman/listinfo/squeakland

_______________________________________________
squeakland mailing list
[hidden email]
http://lists.squeakland.org/mailman/listinfo/squeakland
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: etoys bug?

dcorking
1. Welcome to the mailing list, Dean!

2. There is definitely a problem with the way translucent gradients
redraw when they are 'damaged' by an overlapping morph (I can cause
repainting problems just by clicking the menu halo - it leaves a large
artifact on the gradient.)

Attached is an even further simplified project: a single rectangle
with a translucent gradient! (I am not sure why it is 221 kB ! )

Hope it helps, David

_______________________________________________
squeakland mailing list
[hidden email]
http://lists.squeakland.org/mailman/listinfo/squeakland

translucent-gradient.001.pr (301K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Fwd: etoys bug?

Bert Freudenberg

On 2013-07-10, at 20:03, David Corking <[hidden email]> wrote:

> 1. Welcome to the mailing list, Dean!
>
> 2. There is definitely a problem with the way translucent gradients
> redraw when they are 'damaged' by an overlapping morph (I can cause
> repainting problems just by clicking the menu halo - it leaves a large
> artifact on the gradient.)
>
> Attached is an even further simplified project: a single rectangle
> with a translucent gradient! (I am not sure why it is 221 kB ! )
>
> Hope it helps, David

Yep, a simple bug in BorderedMorph>>areasRemainingToFill:. Andreas fixed it in the squeak.org version back in 2009 :)

I just committed that fix.

- Bert -


_______________________________________________
squeakland mailing list
[hidden email]
http://lists.squeakland.org/mailman/listinfo/squeakland