[OLPC-Games] Activity API
bruno.coudoin at free.fr
Mon Apr 16 19:06:59 EDT 2007
Hi, I have some concern about pygame on the olpc. In fact, until know, I
though activities should use GTK and the hippo canvas.
I understand pygame is more efficient to build games but it has also
- We will have 2 different event loops for sugar and the activity, I
though the main activity concept was about using a single event loop.
- Pygame doesn't use pango, last time I checked there was not support
for shaping in arabic for example (letter shape depends on the previous
- Layout management, usually games are made for a predefined window
size, I though hippo canvas could help in building a dynamic game layout.
- cairo and pygame integration. I know there is a good support of cairo
in GTK, what about pygame.
- Mixing GTK widgets and pygame. It's sometimes useful to use regular
widget in a game, mostly, we sometime use text entries (using all the
different character input GTK support, and the assisted technology) In
the HIG, it's stated that this is important for the OLPC, does pygame
offer a good support for that?
We, in the GCompris project have build and designed over the year a
multi activity application that includes about 100 different activities.
To some extend, GCompris core and Sugar play the same role and looks
very similar in their design. We also support python and can start
python based activities. Based on our 7 years experience in GCompris,
over the year we have build an API that is far from perfect but I
suggest to use it as a draft to implement in sugar these feature. If we
don't create this API that all activity can use, it will be very hard to
make the activities behave consistently and to maintain them over the years.
To give you an example of what's needed, each activity may have several
levels, how do we represent the level to the user, if each activity
implement this, it will be inconsistent.
More important, each activity should provide a translated help, how do
we store and display it, it must be set in a common API.
On our wiki, we have documented all the core services we have set in
common in GCompris:
I don't want to say this can be used 'as is' in sugar, anyway, this code
is in C in GCompris so forget the reuse, but anyway, it can be used as a
draft to define a sugar activity API.
Is there a plan to go this way, does that makes sense?
More information about the Games