etoys-dev September 2009

etoys-dev@lists.squeakfoundation.org

30 participants
68 discussions

Re: logging into showcase from etoys
by teefal 05 Sep '09

05 Sep '09

teefal wrote: > At Fri, 4 Sep 2009 11:52:56 -0400, > Ah, this may help ... file-in the attached changeset from Yoshiki, and > "do" the following code: > yoshiki wrote: > Can you elaborate what you meant by "this may help"? Which part of > what you described above is helped? > This = including the fileout and code to use to set up the servers, so that we're on the same page. > In any case, before making the actual uploading and login works, > talking about tweaking UI may not be the priority. > It works, except for the points I made above. The problems are with user interface primarily. -- Yoshiki _______________________________________________ etoys-dev mailing list etoys-dev(a)squeakland.org http://lists.squeakland.org/mailman/listinfo/etoys-dev[/quote] -------------------- m2f -------------------- (from forum) http://squeakland.org/forums/viewtopic.php?p=10576#10576 -------------------- m2f --------------------

2 2

What about shipping DrGeo in Etoys?
by Hilaire Fernandes 04 Sep '09

04 Sep '09

I discussed it in the past with Bert and Yoshiki. I think it makes sense but what do you think about it? Hilaire

4 9

jira re-arrangement
by Timothy Falconer 04 Sep '09

04 Sep '09

Hi all, Made some changes to JIRA to help with release planning. Please review this JIRA glossary first: http://confluence.immuexa.com/display/sq/Process If the terms don't seem to make sense, then return to the glossary and read them again and again. I've used JIRA with a wide variety of software teams over the last five years, so please rely upon my experience until it becomes more familiar. JIRA is used by Apache and many other large open-source projects ... there's truly a "there" there, but only if you relax and use it as it was designed to be used. The changes: 1. "must-have" = critical priority 2. "desirable" = normal priority 3. "possible" = eventual priority 4. "desirable but complex or risky" = optional priority 5. "published!" = closed 6. "ready for testing" = resolved 7. "internationalization" = moved in with the rest (in 4.1 release) 8. "pango" = moved in with the rest (in 4.1 release) 9. "dormant, residual, historical" = optional priority in someday release 10. two big versions ... "etoys 4.0 - summer 2009" and "etoys 4.1 - winter 2010" (summers will be even numbered, winters will be odd numbered) The reason for all of this is so that we can actually look at the roadmap and see where we are. Things were too fragmented. They were going against the way JIRA works. So now, there's three release bins showing on the roadmap: a. review ... all new stuff goes here and gets moved elsewhere after discussion b. etoys 4.0 ... current release c. biz/ed ... these are the non-Etoys items that the business and education teams must do There will always be these three at the top of the release road map ... click "all versions" to see etoys 4.1, etc. Anyway, I hope this makes things clearer. As you continue to use JIRA, you'll see that many tools exist that require this functionality. (Try "Find Issues", for example, then click "New".) So if you're wondering: * what should I test? Click "Resolved" under Project Summary o see a list of resolved issues. These need testing. Add a comment saying, "works for me" and then put the change to the update stream and click "Closed" (aka Published) Would other words be more clear? Perhaps to some. In my opinion, let's all try to learn these five states (scheduled, in progress, resolved, closed) and five priorities (blocker, critical, normal, eventual, optional). They work. Also, remember ... the best view is "road map" ... it sorts by priority into releases. It also has a nifty green & red progress bar that motivates. Now, I'm going back into my post-Squeakfest cave for a while ... in the next week or so, please help move things in "review" or "etoys 4.0" that we can't do easily in the next few weeks to "etoys 4.1" Our overall goal is to have Etoys 4.0 be all green in the roadmap. Another goal is to have zero issues in "review". Sorry for the draconian changes, but I couldn't get my finger on the pulse of the release the way it was. This is a better way to work. Tim

4 13

Re: [squeakland] Etoys documentation TOC
by Rita Freudenberg 04 Sep '09

04 Sep '09

Timothy Falconer wrote: > On Sep 3, 2009, at 7:23 AM, Timothy Falconer wrote: > >> On Sep 3, 2009, at 7:01 AM, Rita Freudenberg wrote: >> >>> Hi all, >>> >>> as you all know we don't really have an Etoys documentation. So >>> let's start writing it. As I wrote earlier I propose to use FLOSS >>> Manuals. It is used by the olpc and sugar community for writing >>> manuals and books. To get started we should have a TOC outline. Here >>> are my suggestions: >>> >>> 1. Introduction (short description what etoys is about) >>> 2. Getting started (technical description on how to install and >>> start etoys on different operating systems) >>> 3. User Interface (painting tools, halo, viewer ...) >>> 4. Tiles (describing every available tile) >>> 5. Objects (everything from the supplies bin and object catalogue, >>> flaps) >>> >>> What am I missing? Of course we can have subchapters and also later >>> add main chapters if we find out we need it. Here is the manual for >>> TurtleArt so you can get the idea what our documentation could look >>> like: >>> http://en.flossmanuals.net/turtleart >>> >>> What do you think? If we come up with a TOC outline I can send it to >>> Anne Gentle from FLOSS manuals to set it up and we can start writing:) >> >> It's a good list. So this would be more of a reference manual than a >> getting started guide? (with tutorials) Yes, a reference manual is what I had in mind. I'm sorry for not making that clear. >> >> We could link back to the Etoys unit of the courseware for the >> gentler intro. > > Also, just want to highlight that we actually do have some > documentation (with even a big PDF): > > http://squeakland.org/tutorials/guides/ > > Kathleen's work is concise and useful, and should be used where > possible in the FLOSS version. Definitely, I will not have the same things written again, but collect it at one place. And since it is a reference manual, it will be shorter than other materials, but complete. As Bert pointed out "it defines the boundary of what we consider officially supported, and what not." Rita > > Tim -- Rita Freudenberg FIN-ISG Otto-von-Guericke-Universität Magdeburg http://isgwww.cs.uni-magdeburg.de/isg/rita.html

1 0

Etoys documentation TOC
by Rita Freudenberg 03 Sep '09

03 Sep '09

Hi all, as you all know we don't really have an Etoys documentation. So let's start writing it. As I wrote earlier I propose to use FLOSS Manuals. It is used by the olpc and sugar community for writing manuals and books. To get started we should have a TOC outline. Here are my suggestions: 1. Introduction (short description what etoys is about) 2. Getting started (technical description on how to install and start etoys on different operating systems) 3. User Interface (painting tools, halo, viewer ...) 4. Tiles (describing every available tile) 5. Objects (everything from the supplies bin and object catalogue, flaps) What am I missing? Of course we can have subchapters and also later add main chapters if we find out we need it. Here is the manual for TurtleArt so you can get the idea what our documentation could look like: http://en.flossmanuals.net/turtleart What do you think? If we come up with a TOC outline I can send it to Anne Gentle from FLOSS manuals to set it up and we can start writing:) Greetings, Rita -- Rita Freudenberg FIN-ISG Otto-von-Guericke-Universität Magdeburg http://isgwww.cs.uni-magdeburg.de/isg/rita.html

7 7

Players and costumes
by Bert Freudenberg 03 Sep '09

03 Sep '09

On 01.09.2009, at 04:07, tracker(a)squeakland.org wrote: > Scott Wallace updated SQ-288: > ----------------------------- > > Attachment: lookLikeBug-sw.2.cs.gz > > Version 2 uploaded: > (a) Restricts the 'look like' tile to be available only in the > viewers of Sketches; this makes it still compatible with the > "powerful ideas" book, and with other support materials, while not > tempting users to deploy it with non-sketch receivers. > (b) 'look like' execution now consists of assigning a new graphic, > rather than touching the buggy and dangerous morph-substitution code > of old. This avoids the pernicious bug that is the subject of this > ticket. So that means a player cannot change its custome anymore, right? Isn't that a fundamental change in the Etoys philosophy? If players and costumes are inseparable, why even talk about them separately? It would appear as if we now have different kinds of players, when before there was only one kind. How would we communicate the player-costume relationship then? Or do we just say that's an implementation detail? - Bert -

4 4

Re: weekly time for etoys-dev IRC chat
by Timothy Falconer 02 Sep '09

02 Sep '09

Still waiting for people to add themselves to the doodle calendar thing: http://www.doodle.com/akyp86qi3kfvyqrq Still missing Scott, Ted, Yoshiki, Takashi, Karl, and more people from the larger etoys-dev community. Also seems like Bert & Walter can never make it at the same time : ( Any wiggle room guys? Tim On Aug 31, 2009, at 9:00 AM, Timothy Falconer wrote: > Ah, here's the doodle link: > > http://www.doodle.com/akyp86qi3kfvyqrq > > Please add your available times here. > > > On Aug 31, 2009, at 8:56 AM, Timothy Falconer wrote: > >> >> Hi everyone, >> >> We're opening up our weekly Etoys software chats to anyone that >> wants to attend, using the #etoys channel on irc.freenode.org. >> >> You can also attend using a web-browser by clicking "chat" on squeakland.org >> . >> >> First we need to find the best time for everyone. >> >> I've created a doodle that has slots for 12 noon New York time to >> 5pm New York time. This accommodates the people in California and >> the people in New York & Cambridge & Toronto. >> >> Please add your available times if you'd like to attend weekly. >> Meeting times will be an hour or less. >> >> Thanks, >> Tim > -- Timothy Falconer Immuexa Corporation http://immuexa.com 610-797-3100

1 0

popups in project-info
by antonio 01 Sep '09

01 Sep '09

Rita's approach is what we use at Extremadura till now (because we did her reasoning time ago): for teachers: http://squeak.educarex.es/Squeakpolis/56 Pure web; it is neccesary access control: only persons with log can put material here; for everybody: http://squeak.educarex.es:9090/seaside/SBSuperSwiki?_s=jYdpUYJXctSCQeXo&_k=… sswiki accesible desde Squeak, everybody can use it. We are not sure it is the best system, of course, but previously we had only one repo and teachers despaired seeing "pilot projects" (some times explendid really) but who do not say anything to them, because "by default" they seek "material over", prepared for use at the classroom. greetings

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

etoys-dev September 2009