Etoys in Javascript

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

Etoys in Javascript

Harness, Kathleen
Hi Jecel,
Let's keep "compatibility with current projects" at the top of our requirements for the changes to Etoys being considered here. I know Bert mentioned this recently and I am very grateful that he values what we have been doing here in Illinois.

If the library collection of projects on EtoysIllinois will not run in Etoys it would be the end of us. We can not meet again with the hundreds of students who made those projects.

The example projects and lesson materials were developed in classrooms and reflect years of experimentation with project ideas that make programming relevant to young children's interests and knowledge.

Kathleen

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

Re: Etoys in Javascript

Bert Freudenberg

On 2013-05-24, at 14:22, "Harness, Kathleen" <[hidden email]> wrote:

> Hi Jecel,
> Let's keep "compatibility with current projects" at the top of our requirements for the changes to Etoys being considered here. I know Bert mentioned this recently and I am very grateful that he values what we have been doing here in Illinois.
>
> If the library collection of projects on EtoysIllinois will not run in Etoys it would be the end of us. We can not meet again with the hundreds of students who made those projects.
>
> The example projects and lesson materials were developed in classrooms and reflect years of experimentation with project ideas that make programming relevant to young children's interests and knowledge.

Kathleen,

would converting the projects be okay? Meaning, suppose the "Javascript Etoys" couldn't read the old project files directly, but there was a way to export a project from Squeak Etoys into another file that could be imported by Javascript Etoys, would that be sufficient?

- Bert -

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

Re: Etoys in Javascript

Jecel Assumpcao Jr

Kathleen Harness wrote:
> > Let's keep "compatibility with current projects" at the top of our requirements
> > for the changes to Etoys being considered here.

I fully agree with that priority. Note that we were talking about a
completely new Etoys and not a changed one. I was just trying to make
clear what the cost of the different options are.

> > I know Bert mentioned this recently and I am very grateful that he values what
> > we have been doing here in Illinois.
> >
> > If the library collection of projects on EtoysIllinois will not run in Etoys it would
> > be the end of us. We can not meet again with the hundreds of students who
> > made those projects.
> >
> > The example projects and lesson materials were developed in classrooms and
> > reflect years of experimentation with project ideas that make programming
> > relevant to young children's interests and knowledge.

Yes, that is far more important than any specific Etoys feature in my
opinion as well. In the Squeak community, after Edgar De Cleene it is
likely that I have been the most vocal about keeping old stuff working.

Bert Freudenberg wrote:
> would converting the projects be okay? Meaning, suppose the "Javascript Etoys"
> couldn't read the old project files directly, but there was a way to export a project
> from Squeak Etoys into another file that could be imported by Javascript Etoys,
> would that be sufficient?

That sounds like an interesting plan. I had only though about putting
all of the conversion work in the new system, but it is true that some
things are easier to do inside the original system. It might be the case
that getting 100% of the projects converted is really hard but 97% is
reasonably easy. It would be a good idea to find out, specially if the
3% turn out not to be among the most important projects.

-- Jecel

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

Re: Etoys in Javascript

Harness, Kathleen
In reply to this post by Bert Freudenberg
Jecel,
97%, sounds good to me. There are early projects from 7 or 8 years ago that are not as well done as the later ones. As I became a better teacher, so too did my student's projects.

I do not understand all the steps a visitor to our site would need to take to get one of those projects to open. The fewer steps the better, the fewer roadblock hurdles to get over the better especially for young children or cautious adult beginners.
Have a good weekend, it is sunny and cool here.
Regards,
Kathleen
________________________________________
From: [hidden email] [[hidden email]] on behalf of Jecel Assumpcao Jr. [[hidden email]]
Sent: Friday, May 24, 2013 2:37 PM
To: [hidden email] dev
Subject: Re: [etoys-dev] Etoys in Javascript

Kathleen Harness wrote:
> > Let's keep "compatibility with current projects" at the top of our requirements
> > for the changes to Etoys being considered here.

I fully agree with that priority. Note that we were talking about a
completely new Etoys and not a changed one. I was just trying to make
clear what the cost of the different options are.

> > I know Bert mentioned this recently and I am very grateful that he values what
> > we have been doing here in Illinois.
> >
> > If the library collection of projects on EtoysIllinois will not run in Etoys it would
> > be the end of us. We can not meet again with the hundreds of students who
> > made those projects.
> >
> > The example projects and lesson materials were developed in classrooms and
> > reflect years of experimentation with project ideas that make programming
> > relevant to young children's interests and knowledge.

Yes, that is far more important than any specific Etoys feature in my
opinion as well. In the Squeak community, after Edgar De Cleene it is
likely that I have been the most vocal about keeping old stuff working.

Bert Freudenberg wrote:
> would converting the projects be okay? Meaning, suppose the "Javascript Etoys"
> couldn't read the old project files directly, but there was a way to export a project
> from Squeak Etoys into another file that could be imported by Javascript Etoys,
> would that be sufficient?

That sounds like an interesting plan. I had only though about putting
all of the conversion work in the new system, but it is true that some
things are easier to do inside the original system. It might be the case
that getting 100% of the projects converted is really hard but 97% is
reasonably easy. It would be a good idea to find out, specially if the
3% turn out not to be among the most important projects.

-- Jecel

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

Re: Etoys in Javascript

Steve Thomas
So following up on Alan's quote:
"Better" and "Perfect" are the enemies of "What Is Needed"

Let me voice one opinion on what is needed:
  1. The ability to run in a Browser
  2. The ability to run on Mobile Devices (IPhone/Android)
    1. How many more kids would be turned onto Etoys (and more importantly the ideas they could explore an learn using Etoys) if they could in a matter of an hour create a iPhone/Android app?
  3. The ability to run on Tablets (iPad/Android Tablet)
  4. The ability to run without an Internet connection
    1. I am thinking about XO deployments and schools with Internet restrictions
    2. Also the ability to run from  USB would be great (I love Etoys to Go)
  5. The ability to run ~97% of existing Etoys projects
    1. My guess is the vast majority of  Etoys projects do not use a lot of the features of Etoys
    2. We could run the utility Bert created for me a while back to determine which Scripting tiles (and object?) are in a project to scan through the Etoys Illinois projects and get an idea on what would be the "basics" to start with.  I can help with that (the scripting anyway) if needed.
    3. I wouldn't mind a tool to "convert" existing Etoys projects to "Javascript Etoys" projects.  We could run a converter and provide both versions in a single click from the Etoys Illinois site and also to allow folks to convert their existing projects.
    4. Books and Playfields are one addition I can think of immediately that would be needed
    5. Only concern would be Kedama, I would hate to lose that.

Some thoughts on the enemies of "Better" and "Perfect"
  1. Authoring Always On
    1. Better/Perfect yes, Realistic and Needed on the screensize of an iPhone/Android, hmmm
    2. We can probably get a "runnable" version of Etoys (ie: no getting Halos or scripting) on iPhone/Android a lot faster than a "Authoring On" version that would frustrate all but those with the smallest fingers, pin point dexterity and the patience and perseverance of of a Saint.
    3. By what date do we realistically expect Apple to "see the light" and allow authoring on version of Etoys?
  2. We need a Good design for a Touch Interface
    1. Agreed, but how long will this take, do we need to wait for this to deploy a runnable version on iPhone/iPad/Android. Still we would need a "Touch interface" to work for "non authoring" gestures. (I obviously need to think about this more)

Build on top of Snap or Lively or ??? (like most things I am NOT an expert here, but that never stopped me from thinking about it and voicing my opinion :)
Both Snap and Lively Kernel run on my Android, but both had issues which would need to be addressed.  The one thing I like about Lively (and perhaps this could be added to Snap) is the ability to add Java Script to do what you wanted.  This is a nice feature and would guess would attract more developers.

I really like the scripting tile interface in Scratch/BYOB (colore tiles, tile shapes, snap-a-bility and flaps) as compared to the scripting tiles and viewers in Etoys.

Cheers,
Stephen

On Fri, May 24, 2013 at 4:43 PM, Harness, Kathleen <[hidden email]> wrote:
Jecel,
97%, sounds good to me. There are early projects from 7 or 8 years ago that are not as well done as the later ones. As I became a better teacher, so too did my student's projects.

I do not understand all the steps a visitor to our site would need to take to get one of those projects to open. The fewer steps the better, the fewer roadblock hurdles to get over the better especially for young children or cautious adult beginners.
Have a good weekend, it is sunny and cool here.
Regards,
Kathleen
________________________________________
From: [hidden email] [[hidden email]] on behalf of Jecel Assumpcao Jr. [[hidden email]]
Sent: Friday, May 24, 2013 2:37 PM
To: [hidden email] dev
Subject: Re: [etoys-dev] Etoys in Javascript

Kathleen Harness wrote:
> > Let's keep "compatibility with current projects" at the top of our requirements
> > for the changes to Etoys being considered here.

I fully agree with that priority. Note that we were talking about a
completely new Etoys and not a changed one. I was just trying to make
clear what the cost of the different options are.

> > I know Bert mentioned this recently and I am very grateful that he values what
> > we have been doing here in Illinois.
> >
> > If the library collection of projects on EtoysIllinois will not run in Etoys it would
> > be the end of us. We can not meet again with the hundreds of students who
> > made those projects.
> >
> > The example projects and lesson materials were developed in classrooms and
> > reflect years of experimentation with project ideas that make programming
> > relevant to young children's interests and knowledge.

Yes, that is far more important than any specific Etoys feature in my
opinion as well. In the Squeak community, after Edgar De Cleene it is
likely that I have been the most vocal about keeping old stuff working.

Bert Freudenberg wrote:
> would converting the projects be okay? Meaning, suppose the "Javascript Etoys"
> couldn't read the old project files directly, but there was a way to export a project
> from Squeak Etoys into another file that could be imported by Javascript Etoys,
> would that be sufficient?

That sounds like an interesting plan. I had only though about putting
all of the conversion work in the new system, but it is true that some
things are easier to do inside the original system. It might be the case
that getting 100% of the projects converted is really hard but 97% is
reasonably easy. It would be a good idea to find out, specially if the
3% turn out not to be among the most important projects.

-- Jecel

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



--

To some of us, writing computer programs is a fascinating game. A program is a building of thought. It is costless to build, weightless, growing easily under our typing hands. If we get carried away, its size and complexity will grow out of control, confusing even the one who created it. This is the main problem of programming. It is why so much of today's software tends to crash, fail, screw up.

When a program works, it is beautiful. The art of programming is the skill of controlling complexity. The great program is subdued, made simple in its complexity.

- Martin Harverbeke (from Eloquent JavaScript)


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

Re: Etoys in Javascript

dcorking
I stole one of Steve's sentences, and changed the objects for my own
nefarious purposes:

'Build on top of Amber ???  The one thing I like about Amber is the
ability to add Smalltalk to do what you wanted.'

Let's consider the possibility of Smalltalk in the browser as a
possible tool to build an Etoys-like learning environment.
http://amber-lang.net/

Steve wrote:
'By what date do we realistically expect Apple to "see the light" and
allow authoring on version of Etoys?'

Never, but with network access an Etoys-like app in the web browser
could save to a remote server without ever needing to be approved by
Apple's app store. By the same token, "never" means you never get
access to the attitude sensor, accelerometer and other fun gadgets
unless Apple makes them available to all web developers.

My 2p. David
_______________________________________________
etoys-dev mailing list
[hidden email]
http://lists.squeakland.org/mailman/listinfo/etoys-dev
Reply | Threaded
Open this post in threaded view
|

Re: Etoys in Javascript

Steve Thomas
In reply to this post by Steve Thomas
So one more "need" I forgot: The ability to run from a USB stick on Mac/Windows/Linux (ie: Etoys to Go
Etoys-to-Go is so cool and useful.

Cheers,
Stephen

On Sat, May 25, 2013 at 1:06 AM, Steve Thomas <[hidden email]> wrote:
So following up on Alan's quote:
"Better" and "Perfect" are the enemies of "What Is Needed"

Let me voice one opinion on what is needed:
  1. The ability to run in a Browser
  2. The ability to run on Mobile Devices (IPhone/Android)
    1. How many more kids would be turned onto Etoys (and more importantly the ideas they could explore an learn using Etoys) if they could in a matter of an hour create a iPhone/Android app?
  3. The ability to run on Tablets (iPad/Android Tablet)
  4. The ability to run without an Internet connection
    1. I am thinking about XO deployments and schools with Internet restrictions
    2. Also the ability to run from  USB would be great (I love Etoys to Go)
  5. The ability to run ~97% of existing Etoys projects
    1. My guess is the vast majority of  Etoys projects do not use a lot of the features of Etoys
    2. We could run the utility Bert created for me a while back to determine which Scripting tiles (and object?) are in a project to scan through the Etoys Illinois projects and get an idea on what would be the "basics" to start with.  I can help with that (the scripting anyway) if needed.
    3. I wouldn't mind a tool to "convert" existing Etoys projects to "Javascript Etoys" projects.  We could run a converter and provide both versions in a single click from the Etoys Illinois site and also to allow folks to convert their existing projects.
    4. Books and Playfields are one addition I can think of immediately that would be needed
    5. Only concern would be Kedama, I would hate to lose that.

Some thoughts on the enemies of "Better" and "Perfect"
  1. Authoring Always On
    1. Better/Perfect yes, Realistic and Needed on the screensize of an iPhone/Android, hmmm
    2. We can probably get a "runnable" version of Etoys (ie: no getting Halos or scripting) on iPhone/Android a lot faster than a "Authoring On" version that would frustrate all but those with the smallest fingers, pin point dexterity and the patience and perseverance of of a Saint.
    3. By what date do we realistically expect Apple to "see the light" and allow authoring on version of Etoys?
  2. We need a Good design for a Touch Interface
    1. Agreed, but how long will this take, do we need to wait for this to deploy a runnable version on iPhone/iPad/Android. Still we would need a "Touch interface" to work for "non authoring" gestures. (I obviously need to think about this more)

Build on top of Snap or Lively or ??? (like most things I am NOT an expert here, but that never stopped me from thinking about it and voicing my opinion :)
Both Snap and Lively Kernel run on my Android, but both had issues which would need to be addressed.  The one thing I like about Lively (and perhaps this could be added to Snap) is the ability to add Java Script to do what you wanted.  This is a nice feature and would guess would attract more developers.

I really like the scripting tile interface in Scratch/BYOB (colore tiles, tile shapes, snap-a-bility and flaps) as compared to the scripting tiles and viewers in Etoys.

Cheers,
Stephen

On Fri, May 24, 2013 at 4:43 PM, Harness, Kathleen <[hidden email]> wrote:
Jecel,
97%, sounds good to me. There are early projects from 7 or 8 years ago that are not as well done as the later ones. As I became a better teacher, so too did my student's projects.

I do not understand all the steps a visitor to our site would need to take to get one of those projects to open. The fewer steps the better, the fewer roadblock hurdles to get over the better especially for young children or cautious adult beginners.
Have a good weekend, it is sunny and cool here.
Regards,
Kathleen
________________________________________
From: [hidden email] [[hidden email]] on behalf of Jecel Assumpcao Jr. [[hidden email]]
Sent: Friday, May 24, 2013 2:37 PM
To: [hidden email] dev
Subject: Re: [etoys-dev] Etoys in Javascript

Kathleen Harness wrote:
> > Let's keep "compatibility with current projects" at the top of our requirements
> > for the changes to Etoys being considered here.

I fully agree with that priority. Note that we were talking about a
completely new Etoys and not a changed one. I was just trying to make
clear what the cost of the different options are.

> > I know Bert mentioned this recently and I am very grateful that he values what
> > we have been doing here in Illinois.
> >
> > If the library collection of projects on EtoysIllinois will not run in Etoys it would
> > be the end of us. We can not meet again with the hundreds of students who
> > made those projects.
> >
> > The example projects and lesson materials were developed in classrooms and
> > reflect years of experimentation with project ideas that make programming
> > relevant to young children's interests and knowledge.

Yes, that is far more important than any specific Etoys feature in my
opinion as well. In the Squeak community, after Edgar De Cleene it is
likely that I have been the most vocal about keeping old stuff working.

Bert Freudenberg wrote:
> would converting the projects be okay? Meaning, suppose the "Javascript Etoys"
> couldn't read the old project files directly, but there was a way to export a project
> from Squeak Etoys into another file that could be imported by Javascript Etoys,
> would that be sufficient?

That sounds like an interesting plan. I had only though about putting
all of the conversion work in the new system, but it is true that some
things are easier to do inside the original system. It might be the case
that getting 100% of the projects converted is really hard but 97% is
reasonably easy. It would be a good idea to find out, specially if the
3% turn out not to be among the most important projects.

-- Jecel

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



--

To some of us, writing computer programs is a fascinating game. A program is a building of thought. It is costless to build, weightless, growing easily under our typing hands. If we get carried away, its size and complexity will grow out of control, confusing even the one who created it. This is the main problem of programming. It is why so much of today's software tends to crash, fail, screw up.

When a program works, it is beautiful. The art of programming is the skill of controlling complexity. The great program is subdued, made simple in its complexity.

- Martin Harverbeke (from Eloquent JavaScript)




--

To some of us, writing computer programs is a fascinating game. A program is a building of thought. It is costless to build, weightless, growing easily under our typing hands. If we get carried away, its size and complexity will grow out of control, confusing even the one who created it. This is the main problem of programming. It is why so much of today's software tends to crash, fail, screw up.

When a program works, it is beautiful. The art of programming is the skill of controlling complexity. The great program is subdued, made simple in its complexity.

- Martin Harverbeke (from Eloquent JavaScript)


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

Re: Etoys in Javascript

Harness, Kathleen
Steve,
Yes, Etoys-to-Go is needed.

On June 4th, Etoys-to-Go is being put to good use in Champaign. We will provide Introduction to Programming with Etoys workshops for 300 high school freshman. http://illinois.edu/calendar/detail/3009/28788721  We have workshop leaders from Unit 4 schools, MSTE and Computer Science UIUC. There will be three 90 minute sessions in each of five computer labs. It will be quite a day.

Each student will use a flash drive with Etoys-to-Go in the workshop and then take it home. The flash drive also includes videos lessons, print lessons and example projects.

Etoys-to-Go means there will be ripples of learning that expand out from the short workshops into the community of friends and families. The workshop would not have anywhere near the same impact if they could not take the software with them.
Regards,
Kathleen

From: [hidden email] [[hidden email]] on behalf of Steve Thomas [[hidden email]]
Sent: Saturday, May 25, 2013 10:28 PM
To: Harness, Kathleen
Cc: Jecel Assumpcao Jr.; [hidden email] dev
Subject: Re: [etoys-dev] Etoys in Javascript

So one more "need" I forgot: The ability to run from a USB stick on Mac/Windows/Linux (ie: Etoys to Go
Etoys-to-Go is so cool and useful.

Cheers,
Stephen

On Sat, May 25, 2013 at 1:06 AM, Steve Thomas <[hidden email]> wrote:
So following up on Alan's quote:
"Better" and "Perfect" are the enemies of "What Is Needed"

Let me voice one opinion on what is needed:
  1. The ability to run in a Browser
  2. The ability to run on Mobile Devices (IPhone/Android)
    1. How many more kids would be turned onto Etoys (and more importantly the ideas they could explore an learn using Etoys) if they could in a matter of an hour create a iPhone/Android app?
  3. The ability to run on Tablets (iPad/Android Tablet)
  4. The ability to run without an Internet connection
    1. I am thinking about XO deployments and schools with Internet restrictions
    2. Also the ability to run from  USB would be great (I love Etoys to Go)
  5. The ability to run ~97% of existing Etoys projects
    1. My guess is the vast majority of  Etoys projects do not use a lot of the features of Etoys
    2. We could run the utility Bert created for me a while back to determine which Scripting tiles (and object?) are in a project to scan through the Etoys Illinois projects and get an idea on what would be the "basics" to start with.  I can help with that (the scripting anyway) if needed.
    3. I wouldn't mind a tool to "convert" existing Etoys projects to "Javascript Etoys" projects.  We could run a converter and provide both versions in a single click from the Etoys Illinois site and also to allow folks to convert their existing projects.
    4. Books and Playfields are one addition I can think of immediately that would be needed
    5. Only concern would be Kedama, I would hate to lose that.

Some thoughts on the enemies of "Better" and "Perfect"
  1. Authoring Always On
    1. Better/Perfect yes, Realistic and Needed on the screensize of an iPhone/Android, hmmm
    2. We can probably get a "runnable" version of Etoys (ie: no getting Halos or scripting) on iPhone/Android a lot faster than a "Authoring On" version that would frustrate all but those with the smallest fingers, pin point dexterity and the patience and perseverance of of a Saint.
    3. By what date do we realistically expect Apple to "see the light" and allow authoring on version of Etoys?
  2. We need a Good design for a Touch Interface
    1. Agreed, but how long will this take, do we need to wait for this to deploy a runnable version on iPhone/iPad/Android. Still we would need a "Touch interface" to work for "non authoring" gestures. (I obviously need to think about this more)

Build on top of Snap or Lively or ??? (like most things I am NOT an expert here, but that never stopped me from thinking about it and voicing my opinion :)
Both Snap and Lively Kernel run on my Android, but both had issues which would need to be addressed.  The one thing I like about Lively (and perhaps this could be added to Snap) is the ability to add Java Script to do what you wanted.  This is a nice feature and would guess would attract more developers.

I really like the scripting tile interface in Scratch/BYOB (colore tiles, tile shapes, snap-a-bility and flaps) as compared to the scripting tiles and viewers in Etoys.

Cheers,
Stephen

On Fri, May 24, 2013 at 4:43 PM, Harness, Kathleen <[hidden email]> wrote:
Jecel,
97%, sounds good to me. There are early projects from 7 or 8 years ago that are not as well done as the later ones. As I became a better teacher, so too did my student's projects.

I do not understand all the steps a visitor to our site would need to take to get one of those projects to open. The fewer steps the better, the fewer roadblock hurdles to get over the better especially for young children or cautious adult beginners.
Have a good weekend, it is sunny and cool here.
Regards,
Kathleen
________________________________________
From: [hidden email] [[hidden email]] on behalf of Jecel Assumpcao Jr. [[hidden email]]
Sent: Friday, May 24, 2013 2:37 PM
To: [hidden email] dev
Subject: Re: [etoys-dev] Etoys in Javascript

Kathleen Harness wrote:
> > Let's keep "compatibility with current projects" at the top of our requirements
> > for the changes to Etoys being considered here.

I fully agree with that priority. Note that we were talking about a
completely new Etoys and not a changed one. I was just trying to make
clear what the cost of the different options are.

> > I know Bert mentioned this recently and I am very grateful that he values what
> > we have been doing here in Illinois.
> >
> > If the library collection of projects on EtoysIllinois will not run in Etoys it would
> > be the end of us. We can not meet again with the hundreds of students who
> > made those projects.
> >
> > The example projects and lesson materials were developed in classrooms and
> > reflect years of experimentation with project ideas that make programming
> > relevant to young children's interests and knowledge.

Yes, that is far more important than any specific Etoys feature in my
opinion as well. In the Squeak community, after Edgar De Cleene it is
likely that I have been the most vocal about keeping old stuff working.

Bert Freudenberg wrote:
> would converting the projects be okay? Meaning, suppose the "Javascript Etoys"
> couldn't read the old project files directly, but there was a way to export a project
> from Squeak Etoys into another file that could be imported by Javascript Etoys,
> would that be sufficient?

That sounds like an interesting plan. I had only though about putting
all of the conversion work in the new system, but it is true that some
things are easier to do inside the original system. It might be the case
that getting 100% of the projects converted is really hard but 97% is
reasonably easy. It would be a good idea to find out, specially if the
3% turn out not to be among the most important projects.

-- Jecel

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



--

To some of us, writing computer programs is a fascinating game. A program is a building of thought. It is costless to build, weightless, growing easily under our typing hands. If we get carried away, its size and complexity will grow out of control, confusing even the one who created it. This is the main problem of programming. It is why so much of today's software tends to crash, fail, screw up.

When a program works, it is beautiful. The art of programming is the skill of controlling complexity. The great program is subdued, made simple in its complexity.

- Martin Harverbeke (from Eloquent JavaScript)




--

To some of us, writing computer programs is a fascinating game. A program is a building of thought. It is costless to build, weightless, growing easily under our typing hands. If we get carried away, its size and complexity will grow out of control, confusing even the one who created it. This is the main problem of programming. It is why so much of today's software tends to crash, fail, screw up.

When a program works, it is beautiful. The art of programming is the skill of controlling complexity. The great program is subdued, made simple in its complexity.

- Martin Harverbeke (from Eloquent JavaScript)


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

Re: Etoys in Javascript

Bert Freudenberg
In reply to this post by dcorking
Guys,

you still don't understand Apple's policy.

On 2013-05-25, at 16:14, David Corking <[hidden email]> wrote:

> Steve wrote:
>> 'By what date do we realistically expect Apple to "see the light" and
>> allow authoring on version of Etoys?'
>>
> Never,

Again, Apple does *not* oppose authoring. There are many authoring apps in the app store already.

What they oppose to is *running downloaded code*. That unfortunately includes opening Etoys projects from the Web or Email etc. Creating an Etoys project on the iPad itself would not be a problem. Neither is shipping example projects with the app.

So, in fact, I think it would be fine to build an "etoys illinois" iPad app that includes all projects. It might be somewhat large though ...

> but with network access an Etoys-like app in the web browser
> could save to a remote server without ever needing to be approved by
> Apple's app store.

Right.

> By the same token, "never" means you never get
> access to the attitude sensor, accelerometer and other fun gadgets
> unless Apple makes them available to all web developers.


Accelerometer data on iOS devices has been available to web developers since 2010.

- Bert -

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