[sugar] Native activities (was Re: All GCompris activities available)

[Bert Freudenberg]

On Sep 24, 2007, at 1:22 , Albert Cahalan wrote:

> I know. That's a lot of mostly-unrelated code. I was
> hoping you could point to the critical changes that
> must be made to any random app.
>
> Really I'd just like nice documentation.

Oh me too. With a double-plus.

> In the absense of that, I'm trying to guess the API from your code.

I have been doing exactly that - guessing the API from the code, from  
the default implementation code that is (the Python Sugar  
implementation). And I documented my findings here:

http://wiki.laptop.org/go/Activity_DBus_API

The problem is that this page only describes the plumbing material,  
but not the desired flow. Without a good understanding of how the  
system is supposed to work it's probably hard, if not impossible to  
use that info.

At least the factory part you can ignore for now and just use the  
sugar-native-activity I first implemented for Etoys and is now used  
by GCompris, too. The C code was moved to Sugar.

> Do you handle the journal?

Etoys does - in the Sugar codebase it's called "datastore" though. I  
have put my findings about the datastore on the same page. They tend  
to get stale with the API still in flux, but when I change something  
in Etoys to make it work again I usually update that API page, too. I  
could not convince the core developers to keep that page current when  
they change the API, yet.

> Shared activities?

The only thing Etoys does here is getting the list of buddies  
available in the mesh. Proper sharing is not finished yet. But at  
least the Presense Service API is a bit documented:

http://wiki.laptop.org/go/Presence_Service_DBus_API

- Bert -