GObject is everywhere (Sigh...)
Written by
on
in
Young Coders.
Spent the day on OLPCGames today. I'm trying to clean up the code so that the various pieces can be used independently to let people code for the OLPC without giving up portability (and I was hoping, to get GTK totally out of the picture for people not using the GTK-based features, so that you could just run a top-level Pygame window).
So far it's not going all that well. GStreamer, it turns out, is a GObject-based technology, so the video and camera modules are basically wedded to a GTK event-loop. Mesh I already knew would be, but I'd thought those two would be easily separable.
I can replace the camera code with a sub-process running gst-launch, but the video is tied pretty strongly (not a huge loss, without GTK you could only do full-screen display anyway). PangoFont is wedded to the GTK/Cairo/Pango environment. SVGSprite needs Cairo, but should be otherwise pretty independent, but so far it's about the only non-GTK-dependent feature.
At the moment I have a thread that can run in the background to run a gtk event loop and , but I'll have to figure out some way to signal to it that the pygame mainloop has exited in order to prevent hanging or core-dumping. Given that much of the benefit is now gone (since you're almost always going to wind up loading GTK anyway), I may just revert the changes and go back to assuming the embedded operation when you use OLPCGames.
Comments
Comments are closed.
Pingbacks
Pingbacks are closed.
Bert Freudenberg on 12/23/2007 2:07 a.m. #
Actually, there is no need to use GObject. It just wraps underlying functionality - like v4l in the camera case, and dbus for mesh. Now your python bindings might require GTK for that, but other activities use both camera and mesh without a line of GTK code in sight.
Mike Fletcher on 12/23/2007 11:22 a.m. #
It does appear to be the python gstreamer binding that uses the GObject mainloop, rather than gstreamer itself (the binding is delivering the messages to the GObject mainloop from another thread), but that still means either rewriting all of that functionality or going with the existing binding. At the moment going with the existing binding seems more reasonable.