[etoys-dev] How to get a nice EToys based development environment?

[Bert Freudenberg]

On 30.09.2009, at 09:09, Andreas Raab wrote:

> Simon Guest wrote:
>> Am I unusual in wanting to do this?  Is there a better thing to do?
>
> No you're not. I'd like to do the same. Unfortunately the Etoys  
> image is so far behind at this point that it has become a serious  
> hindrance for me. No Monticello, Shout, ToolBuilder, Closures etc.  
> You name it. OTOH, Etoys has all the media activities that are  
> broken in Squeak.
>
> Here is a VHLQ (very high-level question): How do people feel about  
> bringing Squeak.org and Etoys together again? Since the Etoys-haters  
> left, there is both room as well as a need for a driving  
> application. A merger with Etoys would give Squeak back its primary  
> purpose for existence, would allow the Etoys community to benefit  
> from improvements made at Squeak.org and allow of us to focus our  
> efforts in trying to provide a unified artifact for personal dynamic  
> media. We have an open development process that I think could work  
> for such a project so that at the end of the day the Squeakland  
> release may come with a special "skin" for the UI but where the  
> basic system is a Squeak.org image right out of the box.
>
> I'm not sure if we have the resources to do this quickly but I'd  
> like at least to raise the question to see how people feel about it.  
> Is this even option?

IMHO (and as I said previously) it is the *only* option for sustained  
development of Etoys.

So, in a word, yes. Not trivial by any measure but necessary in one  
way or the other.

There was even a coarse plan for how to do it, but I'm not sure if we  
ever wrote it up. Something along the lines of document the current  
UI / behavior (what we consider officially supported in Etoys), and  
when the "new thing" meets the spec, switch over.

Good news is that work on the documentation part is already starting  
(see below).

- Bert -

Begin forwarded message:

> From: Bert Freudenberg <bert at freudenbergs.de>
> Date: 3. September 2009 13:38:12 MESZ
> To: etoys dev <etoys-dev at squeakland.org>, "squeakland.org mailing  
> list" <squeakland at squeakland.org>
> Subject: [etoys-dev] Re: Etoys documentation TOC
>
>
> On 03.09.2009, at 13:23, 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)
>
>
> IMHO that would be much harder to write than a reference manual.  
> It's still desperately needed of course but we should start simple.
>
> The reference manual also serves another purpose: it defines the  
> boundary of what we consider officially supported, and what not. As  
> you know there is much more in Etoys than is easily accessible on  
> the surface. If it's documented, we try hard support it. If not, you  
> may still use it but can't rely on to work in future versions.
>
> - Bert -