As people are probably aware, a .png thumbnail of an etoys project is now put inside the outer .pr file, but for the time being we haven't removed the .gif thumbnail that historically has been put placed *alongside* (rather than *within*) the outer .pr file. See: http://tracker.immuexa.com/browse/SQ-274
Several people have advocated removing the .gif file; it clutters up the Squeaklets directory, for one thing, and it's now redundant, and has only been retained for compatibility with Superswiki and possibly Superswiki 2.
Now the question arises afresh: should we now stop producing the .gif file -- thus requiring Superswiki and other clients who may be interested in a thumbnail to use the embedded .png file?
On the JIRA ticket, in early August, Antonio reported 'That's Masashi answer: "As I seen the code, I think the modification would be quite trivial. I welcome the new, refactored project format."'.
So... do people think the time has now come (in advance of final shipment of this summer's release) to remove the .gif?
-- Scott
On Friday 28 Aug 2009 4:18:17 am Scott Wallace wrote:
So... do people think the time has now come (in advance of final shipment of this summer's release) to remove the .gif?
+1.
In file managers with preview, children often confuse the .gif file for the project.
Subbu
On Aug 28, 2009, at 11:26 AM, K. K. Subramaniam wrote:
On Friday 28 Aug 2009 4:18:17 am Scott Wallace wrote:
So... do people think the time has now come (in advance of final shipment of this summer's release) to remove the .gif?
+1.
In file managers with preview, children often confuse the .gif file for the project.
+1 ... when uploading projects to the website using a web browser (which will become much more common), this can happen as well.
On Aug 31, 2009, at 7:52 AM, Timothy Falconer wrote:
On Aug 28, 2009, at 11:26 AM, K. K. Subramaniam wrote: On Friday 28 Aug 2009 4:18:17 am Scott Wallace wrote:
So... do people think the time has now come (in advance of final shipment of this summer's release) to remove the .gif?
+1.
In file managers with preview, children often confuse the .gif file for the project.
+1 ... when uploading projects to the website using a web browser (which will become much more common), this can happen as well.
A sticking point here continues to be the possibility that existing superswiki, superswiki2, and perhaps other project servers, might rely on the presence of the .gif, and might misbehave if they can't find it.
The JIRA ticket for this issue is http://jira.immuexa.com/browse/SQ-315.
A fileout recently uploaded to that ticket has the comment: "... succeeds in stopping creation of the gif, and also no longer sends the superSwikiServer (if any) the filename of that gif file that used to be created. SuperSwikiServers and other project servers will now need to start using the .png thumbnail embedded in the outer .pr file. Unfortunately, I don't know how to test the consequences this change would have for existing superSwikiServers, etc., so I look to others to help here."
So, this is a call for help. Who among our readership uses, or knows about, superswikis?
(1) It's important to check how existing superswikis contend with projects saved to them using an image that has the ticket's fileout loaded (thus *not* creating a .gif). Is there anyone out there who uses an active superswiki and who can test this? (What about the Etoys/Illinois mechanism for putting projects on their site -- do *they* rely on the .gif?)
(2) At some point, someone needs to undertake modifications to superswiki code so that the thumbnail is extracted from the embedded .png file. I'm not certain how many different superswiki- like systems are in current use, nor who is the current maintainer of each. So please speak up, anyone who can clarify, test, code, or otherwise contribute.
Without at least some testing for consequences with existing superswikis, I think we can't in good conscience stop creating the .gif thumbnail just yet...
-- Scott
On 02.09.2009, at 00:45, Scott Wallace wrote:
On Aug 31, 2009, at 7:52 AM, Timothy Falconer wrote:
On Aug 28, 2009, at 11:26 AM, K. K. Subramaniam wrote: On Friday 28 Aug 2009 4:18:17 am Scott Wallace wrote:
So... do people think the time has now come (in advance of final shipment of this summer's release) to remove the .gif?
+1.
In file managers with preview, children often confuse the .gif file for the project.
+1 ... when uploading projects to the website using a web browser (which will become much more common), this can happen as well.
A sticking point here continues to be the possibility that existing superswiki, superswiki2, and perhaps other project servers, might rely on the presence of the .gif, and might misbehave if they can't find it.
The JIRA ticket for this issue is http://jira.immuexa.com/browse/SQ-315 .
A fileout recently uploaded to that ticket has the comment: "... succeeds in stopping creation of the gif, and also no longer sends the superSwikiServer (if any) the filename of that gif file that used to be created. SuperSwikiServers and other project servers will now need to start using the .png thumbnail embedded in the outer .pr file. Unfortunately, I don't know how to test the consequences this change would have for existing superSwikiServers, etc., so I look to others to help here."
So, this is a call for help. Who among our readership uses, or knows about, superswikis?
(1) It's important to check how existing superswikis contend with projects saved to them using an image that has the ticket's fileout loaded (thus *not* creating a .gif). Is there anyone out there who uses an active superswiki and who can test this? (What about the Etoys/Illinois mechanism for putting projects on their site -- do *they* rely on the .gif?)
(2) At some point, someone needs to undertake modifications to superswiki code so that the thumbnail is extracted from the embedded .png file. I'm not certain how many different superswiki- like systems are in current use, nor who is the current maintainer of each. So please speak up, anyone who can clarify, test, code, or otherwise contribute.
Without at least some testing for consequences with existing superswikis, I think we can't in good conscience stop creating the .gif thumbnail just yet...
My solution to the dilemma would be implementing
http://tracker.squeakland.org/browse/SQ-134
- Bert -
Hello, EtoysIllinois is not a swiki but rather a site designed so I/we could tag and add projects easily. Michael McKelvey, at MSTE/UIUC, designed the site and he can tell you much more.
If the only reason for this proposed change is that some children some times select the .gif instead of the .pr, I would not spend any more time on this and would not make any change. Children learn quickly that a .gif is a picture and .pr is a lot more fun. Kathleen
---- Original message ----
Date: Tue, 1 Sep 2009 15:45:57 -0700 From: Scott Wallace scott.wallace@squeakland.org Subject: Re: [etoys-dev] remove the free-standing .gif? To: etoys dev etoys-dev@squeakland.org
On Aug 31, 2009, at 7:52 AM, Timothy Falconer wrote:
On Aug 28, 2009, at 11:26 AM, K. K. Subramaniam wrote: On Friday 28 Aug 2009 4:18:17 am Scott Wallace wrote:
So... do people think the time has now come (in advance of final shipment of this summer's release) to remove the .gif?
+1.
In file managers with preview, children often confuse the .gif file for the project.
+1 ... when uploading projects to the website using a web browser (which will become much more common), this can happen as well.
A sticking point here continues to be the possibility that existing superswiki, superswiki2, and perhaps other project servers, might rely on the presence of the .gif, and might misbehave if they can't find it.
The JIRA ticket for this issue is http://jira.immuexa.com/browse/SQ-315.
A fileout recently uploaded to that ticket has the comment: "... succeeds in stopping creation of the gif, and also no longer sends the superSwikiServer (if any) the filename of that gif file that used to be created. SuperSwikiServers and other project servers will now need to start using the .png thumbnail embedded in the outer .pr file. Unfortunately, I don't know how to test the consequences this change would have for existing superSwikiServers, etc., so I look to others to help here."
So, this is a call for help. Who among our readership uses, or knows about, superswikis?
(1) It's important to check how existing superswikis contend with projects saved to them using an image that has the ticket's fileout loaded (thus *not* creating a .gif). Is there anyone out there who uses an active superswiki and who can test this? (What about the Etoys/Illinois mechanism for putting projects on their site -- do *they* rely on the .gif?)
(2) At some point, someone needs to undertake modifications to superswiki code so that the thumbnail is extracted from the embedded .png file. I'm not certain how many different superswiki- like systems are in current use, nor who is the current maintainer of each. So please speak up, anyone who can clarify, test, code, or otherwise contribute.
Without at least some testing for consequences with existing superswikis, I think we can't in good conscience stop creating the .gif thumbnail just yet...
-- Scott _______________________________________________ etoys-dev mailing list etoys-dev@squeakland.org http://lists.squeakland.org/mailman/listinfo/etoys-dev
Squeak Developers,
I'm sorry I'm only just replying to this message... I've been out sick all week and am just catching up on email.
Currently, when Kathleen Harness uploads a project to the EtoysIllinois site, she also uploads the GIF image that is automatically generated upon saving an Etoys project. If you are talking about a change wherein a PNG file will be created instead of a GIF file, that would be just fine for our purposes. I am not sure that's what you are talking about, though, as I don't quite understand the following line from the message below:
"start using the .png thumbnail embedded in the outer .pr file"
Could someone please describe what the proposed changes would mean for us, particularly since we are running our server using Apache & PHP, not a Squeak-based webserver like a SuperSwiki? Would we need to be able to somehow extract a PNG file from the PR file? I'm not sure whether we would be able to do that using PHP. Thank you very much for any help you can offer us!
--Michael--
============== Michael McKelvey ============== Office for Mathematics, Science, and Technology Education University of Illinois, Champaign-Urbana MSTE website: http://mste.illinois.edu {Office #: 217-244-7148} {Cell #: 217-621-5783} =========== mmckelve@mste.illinois.edu =========== Current diversion: Dr Horrible (www.drhorrible.com)
----- Original Message ----- From: kharness@illinois.edu To: "Scott Wallace" scott.wallace@squeakland.org; "etoys dev" etoys-dev@squeakland.org Cc: mmckelve@mste.uiuc.edu Sent: Tuesday, September 01, 2009 6:00 PM Subject: Re: [etoys-dev] remove the free-standing .gif?
Hello, EtoysIllinois is not a swiki but rather a site designed so I/we could tag and add projects easily. Michael McKelvey, at MSTE/UIUC, designed the site and he can tell you much more.
If the only reason for this proposed change is that some children some times select the .gif instead of the .pr, I would not spend any more time on this and would not make any change. Children learn quickly that a .gif is a picture and .pr is a lot more fun. Kathleen
---- Original message ----
Date: Tue, 1 Sep 2009 15:45:57 -0700 From: Scott Wallace scott.wallace@squeakland.org Subject: Re: [etoys-dev] remove the free-standing .gif? To: etoys dev etoys-dev@squeakland.org
On Aug 31, 2009, at 7:52 AM, Timothy Falconer wrote:
On Aug 28, 2009, at 11:26 AM, K. K. Subramaniam wrote: On Friday 28 Aug 2009 4:18:17 am Scott Wallace wrote:
So... do people think the time has now come (in advance of final shipment of this summer's release) to remove the .gif?
+1.
In file managers with preview, children often confuse the .gif file for the project.
+1 ... when uploading projects to the website using a web browser (which will become much more common), this can happen as well.
A sticking point here continues to be the possibility that existing superswiki, superswiki2, and perhaps other project servers, might rely on the presence of the .gif, and might misbehave if they can't find it.
The JIRA ticket for this issue is http://jira.immuexa.com/browse/SQ-315.
A fileout recently uploaded to that ticket has the comment: "... succeeds in stopping creation of the gif, and also no longer sends the superSwikiServer (if any) the filename of that gif file that used to be created. SuperSwikiServers and other project servers will now need to start using the .png thumbnail embedded in the outer .pr file. Unfortunately, I don't know how to test the consequences this change would have for existing superSwikiServers, etc., so I look to others to help here."
So, this is a call for help. Who among our readership uses, or knows about, superswikis?
(1) It's important to check how existing superswikis contend with projects saved to them using an image that has the ticket's fileout loaded (thus *not* creating a .gif). Is there anyone out there who uses an active superswiki and who can test this? (What about the Etoys/Illinois mechanism for putting projects on their site -- do *they* rely on the .gif?)
(2) At some point, someone needs to undertake modifications to superswiki code so that the thumbnail is extracted from the embedded .png file. I'm not certain how many different superswiki- like systems are in current use, nor who is the current maintainer of each. So please speak up, anyone who can clarify, test, code, or otherwise contribute.
Without at least some testing for consequences with existing superswikis, I think we can't in good conscience stop creating the .gif thumbnail just yet...
-- Scott _______________________________________________ etoys-dev mailing list etoys-dev@squeakland.org http://lists.squeakland.org/mailman/listinfo/etoys-dev
On 11.09.2009, at 20:53, Michael McKelvey wrote:
Squeak Developers,
I'm sorry I'm only just replying to this message... I've been out sick all week and am just catching up on email.
Currently, when Kathleen Harness uploads a project to the EtoysIllinois site, she also uploads the GIF image that is automatically generated upon saving an Etoys project. If you are talking about a change wherein a PNG file will be created instead of a GIF file, that would be just fine for our purposes. I am not sure that's what you are talking about, though, as I don't quite understand the following line from the message below:
"start using the .png thumbnail embedded in the outer .pr file"
Could someone please describe what the proposed changes would mean for us, particularly since we are running our server using Apache & PHP, not a Squeak-based webserver like a SuperSwiki? Would we need to be able to somehow extract a PNG file from the PR file? I'm not sure whether we would be able to do that using PHP. Thank you very much for any help you can offer us!
You can easily do that on PHP, it is really simple:
An Etoys project file is simply a zip file: =============== Faust:Etoys bert$ unzip -t Heart.001.pr Archive: Heart.001.pr testing: Heart.001.pr OK testing: Heart.001.rc.gz OK testing: Heart.html OK testing: manifest OK testing: thumbnail.png OK No errors detected in compressed data of Heart.001.pr. ===============
So to extract the thumbnail, simply do the equivalent of
=============== Faust:Etoys bert$ unzip Heart.001.pr thumbnail.png Archive: Heart.001.pr extracting: thumbnail.png ===============
See? Easy :)
- Bert -
Quoth the venerable Bert Freudenberg:
On 11.09.2009, at 20:53, Michael McKelvey wrote:
Squeak Developers,
I'm sorry I'm only just replying to this message... I've been out sick all week and am just catching up on email.
Currently, when Kathleen Harness uploads a project to the EtoysIllinois site, she also uploads the GIF image that is automatically generated upon saving an Etoys project. If you are talking about a change wherein a PNG file will be created instead of a GIF file, that would be just fine for our purposes. I am not sure that's what you are talking about, though, as I don't quite understand the following line from the message below:
"start using the .png thumbnail embedded in the outer .pr file"
Could someone please describe what the proposed changes would mean for us, particularly since we are running our server using Apache & PHP, not a Squeak-based webserver like a SuperSwiki? Would we need to be able to somehow extract a PNG file from the PR file? I'm not sure whether we would be able to do that using PHP. Thank you very much for any help you can offer us!
You can easily do that on PHP, it is really simple:
An Etoys project file is simply a zip file:
Faust:Etoys bert$ unzip -t Heart.001.pr Archive: Heart.001.pr testing: Heart.001.pr OK testing: Heart.001.rc.gz OK testing: Heart.html OK testing: manifest OK testing: thumbnail.png OK No errors detected in compressed data of Heart.001.pr. ===============
So to extract the thumbnail, simply do the equivalent of
=============== Faust:Etoys bert$ unzip Heart.001.pr thumbnail.png Archive: Heart.001.pr extracting: thumbnail.png ===============
See? Easy :)
- Bert -
Ok, that is very manageable. How long has the PNG thumbnail been included in the PR file? Is that a relatively new feature?
--Michael--
On 12.09.2009, at 00:58, Michael McKelvey wrote:
Quoth the venerable Bert Freudenberg:
On 11.09.2009, at 20:53, Michael McKelvey wrote:
Squeak Developers,
I'm sorry I'm only just replying to this message... I've been out sick all week and am just catching up on email.
Currently, when Kathleen Harness uploads a project to the EtoysIllinois site, she also uploads the GIF image that is automatically generated upon saving an Etoys project. If you are talking about a change wherein a PNG file will be created instead of a GIF file, that would be just fine for our purposes. I am not sure that's what you are talking about, though, as I don't quite understand the following line from the message below:
"start using the .png thumbnail embedded in the outer .pr file"
Could someone please describe what the proposed changes would mean for us, particularly since we are running our server using Apache & PHP, not a Squeak-based webserver like a SuperSwiki? Would we need to be able to somehow extract a PNG file from the PR file? I'm not sure whether we would be able to do that using PHP. Thank you very much for any help you can offer us!
You can easily do that on PHP, it is really simple:
An Etoys project file is simply a zip file:
Faust:Etoys bert$ unzip -t Heart.001.pr Archive: Heart.001.pr testing: Heart.001.pr OK testing: Heart.001.rc.gz OK testing: Heart.html OK testing: manifest OK testing: thumbnail.png OK No errors detected in compressed data of Heart.001.pr. ===============
So to extract the thumbnail, simply do the equivalent of
=============== Faust:Etoys bert$ unzip Heart.001.pr thumbnail.png Archive: Heart.001.pr extracting: thumbnail.png ===============
See? Easy :)
- Bert -
Ok, that is very manageable. How long has the PNG thumbnail been included in the PR file? Is that a relatively new feature?
It will be included in the upcoming release. You can test using the latest ToGo beta from
http://squeakland.org/download/
(works on Mac, Win, Linux).
- Bert -
At Tue, 1 Sep 2009 15:45:57 -0700, Scott Wallace wrote:
So, this is a call for help. Who among our readership uses, or knows about, superswikis?
Apparently, the image distributed from the Japanese site has default setting to use http://squeakland.jp/super and they get a few submissions per week or so.
But since they also have http://squeakland.jp/super2 that uses SuperSwiki2, and Umezawa-san is already getting ready to work on the png support, we don't have to be concerned about upsetting the old super swiki server there.
(1) It's important to check how existing superswikis contend with projects saved to them using an image that has the ticket's fileout loaded (thus *not* creating a .gif). Is there anyone out there who uses an active superswiki and who can test this? (What about the Etoys/Illinois mechanism for putting projects on their site -- do *they* rely on the .gif?)
I probably can run it on my computer and see what happens.
Kathleen, having a self-contained one file has advantage so we think it is generally a good idea to move toward this direction. It would be nice if Michael McKelvey can add a few lines to his code so that both cases will be supported.
-- Yoshiki
etoys-dev@lists.squeakfoundation.org
-
Bert Freudenberg -
K. K. Subramaniam -
kharness＠illinois.edu -
Michael McKelvey -
Scott Wallace -
Timothy Falconer -
Yoshiki Ohshima