[sugar] Multiple documents

Bert Freudenberg bert at freudenbergs.de
Fri Jul 27 06:23:51 EDT 2007


Seriously folks, this is not just a request for an API extension.

This is *begging* for the non-trivial aspects of the Sugar  
environment to be fleshed out, at least in writing, if not in code.  
We're hopping from trial to trial with patchy interim solutions. And  
this how many months before the kids will have to use this stuff?

Even just this one particular issue: The idea of having kids just  
stop and resume activities is a great one. But I believe that not a  
single non-trivial activity for now resumes to exactly the state it  
was in when stopped. Maybe etoys could come close soon, but only  
because etoys projects were designed from the beginning to be just a  
snapshot of the current UI - and have been refined over several years  
and thus are indeed comparable to what Sugar aspires to. Note this is  
not a "Python vs. Smalltalk" debate, Etoys is just the system I'm  
most familiar with so I take that as example - my view is necessarily  
colored by what I'm working on.

The questions of how multiple activity instances are handled in Sugar  
remains open. And even the way it is handled now is going to be  
replaced "soon" with those security containers which from what I  
heard yet appear to make it even harder to create efficient  
solutions. In the earlier days of Sugar it appeared as if an activity  
implementation would be allowed to manage its instances on its own.  
Step by step this has been made harder. Now it appears to be required  
that every instance is a separate process that starts and lives on  
its own in its virtual container. Which is way inefficient, I  
seriously hope I misunderstand intentions. But requests for detailed  
plans have not been answered either.

Sorry for the rambling, but it appears as if everyone is so immersed  
in their problems at hand that nobody takes time to step back and  
look at the big picture. I've been following the public discussions  
for almost a year now, I'm trying to soak up every bit of information  
I can get, I've even been at the OLPC headquarters for direct  
discussion, but still I feel lost. Yes I read the source, and I even  
documented what I found, thank you. It's not helping for the big  
picture. How anyone could expect external developers to contribute  
anything significant is beyond me.

- Bert -

On Jul 27, 2007, at 9:15 , Tomeu Vizoso wrote:

> Hi Erik,
>
> I suggest that if the datastore API is not enough for your needs,  
> open a
> ticket in trac requesting for multiple file by entry support to be  
> added
> to the DS API.
>
> By now, remember you can just put a set of photographs inside a tar  
> file
> and send that to the DS.
>
> Regards,
>
> Tomeu
>
> On Thu, 2007-07-26 at 19:35 -0400, Erik Blankinship wrote:
>> Was my question so easy that it didn't need a response?  :-)
>>
>> Seriously...  how should activities save/serialize multiple files for
>> correct indexing/viewing in the Journal?  We need an answer  
>> yesterday.
>>
>>
>> On 7/25/07, Erik Blankinship <erikb at mediamods.com> wrote:
>>         I am wondering if there is an answer yet to this question  
>> from
>>         about a month ago?
>>
>>         On 7/12/07, Bert Freudenberg < bert at freudenbergs.de> wrote:
>>                 If I understand the Sugar philosophy correctly, we
>>                 won't have
>>                 multiple documents per activity. If we want to have
>>                 multiple
>>                 documents opened at the same time, these would be
>>                 multiple instances
>>                 of the same activity.
>>
>>                 Is this the case?
>>
>>                 And if so, what would one activity instance have  
>> to do
>>                 to create a
>>                 new instance?
>>
>>                 - Bert -
>>
>>
>>                 _______________________________________________
>>                 Sugar mailing list
>>                 Sugar at lists.laptop.org
>>                 http://lists.laptop.org/listinfo/sugar
>>
>>
>






More information about the Sugar mailing list