[OLPC-Games] GTK+ video target for SDL, first attempt.
Ryan C. Gordon
icculus at icculus.org
Fri Apr 20 19:47:33 EDT 2007
> * An unmodified SDL application should "play nice" with Sugar and not do
> anything inappropriate
I think this should be okay, although I really don't have all the
details of what being well-behaved means. I think we can mostly remove
any polling in SDL, which will help power consumption, and SDL already
provides a means to notify the application of window resizing, in case
someone hits that perspective button on the left front of the screen.
Granted, an app will need to handle resizing well itself, and most SDL
games probably don't, but the mechanism is already there.
We don't have a way to notify the app that the screen's backlight has
turned off and the display has gone to black-and-white mode...we'd
probably consider that a Sugar-specific event (see below), if it's
something that apps are even notified about.
> * It should be relatively easy to modify an SDL app to do everything
> Sugar wants an app to do
> * It should be possible to tweak PyGame so that an unmodified PyGame app
> does everything right
Is there a list of these things somewhere? I think everything that an
SDL or PyGame app expects will mostly be able to work within SDL's usual
mechanisms, and the ones that don't can be cleanly #ifdef'd or whatever.
I don't think we'll need complicated glue code, kludges, and workarounds
in the app itself.
> * There should be some way to get PyGame and PyGTK to cooperate. I don't
> know enough yet to know how much of a problem that will be, except maybe
> a conflict between two main loops, but I hope that we'll be able to work
> out whatever problems there are.
The good news is that SDL_PumpEvents() looks exactly like this in the
So in theory you can avoid calling it altogether, so long as _something_
runs the GTK+ event queue. If PyGTK wants to own it, the events SDL
cares about will still fire their signal callbacks, so SDL_PollEvent()
will still work as expected even if something external pumps the GTK+
event queue. Due to the nature of GTK+ signals, PyGTK and SDL can even
connect the same signals to two different places without causing each
With the GTK+ target in SDL, mostly the conflicts are going to be
questions of basic etiquette, I think, and not big technical tapdancing.
GTK+'s event mechanism is actually pretty darned sweet in this regard.
> We have some Google Summer of Code students who were planning to work on
> all this stuff when they finish class for the year, and that's about
> when my availability will improve as well. It's fantastic that you're
> giving us a head start. If it turns out you have all of this out of the
> way by the time they're ready, there's plenty more for them to do in the
> areas of PyGame extensions and support for the OLPC-specific hardware.
> But if you need or want assistance from them, it will be available in a
> couple of weeks.
Awesome, I didn't know there would be reinforcements coming. :)
I want to go as far as possible with this work, but once the GSoC people
show up, I'd like to have them working out of the SDL Subversion
repository directly, to keep everyone on the same page (and good patches
they make for olpc that are universally good are welcome in the primary
development branch, too, if they want bragging rights and references for
future employers, both of which I happily provide for those with merit).
In an ideal world, I'll have the bulk of the SDL stuff done when they
are ready to start, but we'll see what happens.
I have no experience with PyGame (and almost none with Python), so I'll
definitely leave that to the experts. Mostly I just hope to be helpful
where I can.
More information about the Games