PyGame wrappers and documentation and new developers (Long-ish day with client stuff too...)
Last update on .
Tested the OLPC-Games group's PyGame wrapper on the developer's image. It works nicely on the emulated machine. Looking over the code, they are basically using an SDL feature that lets SDL take over a GTK (or whatever) window in order to integrate into the Sugar desktop.
That is, the application has to have the GTK event loop (GObject event loop) running in there. IIRC the startup time for PyGTK is pretty bad, but it works :) . I spent a while trying to write a minimal non-Hippo, non-GTK, just-PyGame version... but AFAICT you need either the GObject or the Qt event loops running to use python-dbus? That's weird. That would seem to make a raw X application rather difficult. I'm hoping I'm just missing something in there that lets you iterate the dbus communications manually.
Also realised that there are really two dbus services required for each activity, one for the factory, which just provides the "create" method, and one for the introspection API for the individual instance. In Sugar's activities those all run within the same process (all of a given activity's instances share the same process with the factory just starting new window for each instance). Want to see if the multiple-root-window thing works for SDL applications that aren't using a GTK host... if it turns out we don't need the GTK mainloop, that is.
Sat down late this evening and just pounded out some docstrings. Overall docs for the activity package and some for the ClipboardService client object. We still need a heck of a lot of documentation effort.
Another new developer this afternoon (4 yesterday)! Yay! We are so going to make this the best computing platform in the universe... we've just got such awesomely inspiring cuteness on our side.
We're going to do OLPC Toronto Developer's get-togethers. Plan is for this upcoming Thursday for the first one. We'll do introductions, problem-solving, and if we can get time I'd love to get a Sugar-docstring-writing sprint to happen. We've got at least 3 BTest2's, one BTest1 and an ATest board in-town as well, would be nice to test out the networking and try people's activities on the real machines.
Work on the client code didn't go that well. Fixed a few things then realised that some code cruft really needed to be cleaned out, spent a few hours on that... no gentle drift of falling tickets :( .
Comments are closed.
Pingbacks are closed.
John (J5) Palmieri on 04/14/2007 6:24 a.m. #
You need a mainloop to handle events and async calls from D-Bus. Since GTK+ and Qt are the only mainloops that integrate with D-Bus that is what you need to use. Other mainloops can integrate but no one has done it yet.<br />
Also we prefer people use GTK+ in order to integrate with the Sugar environment and provide a consistent environment and API level. PyGame was added to leverage the weath of knowledge and applications written in it. It would be nice if over time, PyGtk+/ PyGame and GTK+/SDL come closer together. (for instance having options for using Cairo and Pango if that is not already possible).
Mike Fletcher on 04/15/2007 1:04 a.m. #
Sure we *prefer* that they integrate. But I'm also wanting to be sure that we *allow* for e.g. raw X applications, applications coded in weird UI libraries, etceteras to integrate. Mobile application developers, for instance, may be writing directly to X (or framebuffer, but that's another issue), making that code easy to port is important to me. We've seen suggestions on sugar list that one could write software in whatever language you choose and easily integrate with Sugar using a dbus service. That may be true, but if you *must* use GTK or Qt, you're nowhere near as free as I'd hoped. Particularly when/if we get GL and GLUT on the platform, they won't be easily supported.
Noah Kantrowitz (coderanger) on 04/26/2007 6:27 p.m. #
While PyGameCanvas is certainly very hackish, GTK/Cairo is simply not an option for 90% of games. Cairo is a vector drawing system, not an image-based system like SDL, which makes game style apps tricky at best. A new GTK video target is being added to SDL, which will hopefully allow access to things like dbus from the SDL event loop somehow.