[OLPC-Games] GTK+ video target for SDL, first attempt.

[Ryan C. Gordon]

> * 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 
GTK+ target:

     while (gtk_events_pending())
         gtk_main_iteration();


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 
other problems.

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.

--ryan.