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 - _______________________________________________ Sugar mailing list [email protected] http://lists.laptop.org/listinfo/sugar
