Using Gstreamer with wxPython – Two MainLoops and the Law of Delimiter

(Original post from 19. May 2012)

Yesterday, while writing on the new version of my super duper honking RPG MusicPlayer, I came across a very interesting problem. Interesting, because it made me learn new things about Python in particular and programming in general.

Gstreamer uses the gobject.MainLoop() to communicate events via messages to its playbin instance. The example below is directly from the tutorial. Note the bus instance and the on_message method. This all runs via the gobject.MainLoop()

        # bus is used to report messages in playtime
        # Taken from tutorial, also the methods
        self.bus = self.player.get_bus()
        self.bus.connect("message", self.on_message)

    def on_message(self, bus, message):
        Taken from gstreamer tutorial.
        Used in:
        - connects to bus in class.
        t = message.type
        if t == gst.MESSAGE_EOS: # track is finished
        elif t == gst.MESSAGE_ERROR:
            err, debug = message.parse_error()
            print "Error: %s" % err, debug

So far, I had no problems not running the gobject.MainLoop, because the wx.App.MainLoop() did all the necessary things to keep my songs running. But at one point, I noticed a bug. When the song came naturally to an end, it would just stop and not play the next song. This was, of course, due to the fact, that the End of Song Message never reached the Playbin, because there was no system to relay said message

At this point, I had the uncomfortable situation of needing two MainLoops to run at the same time. Yes, I know, I should have learned to use pyGTK instead of sticking with wxPython, but I like wxPython and I was lazy. Also, that way I learned loads more funky stuff

Anyways, so how to solve that problem… Well, I used Python’s threading module to help me out here. Without threading, I was not able to start both MainLoops at the same time, because of Python’s procedural nature. Because I had no idea about threading, I had several mishaps on the way, but I came up with a minimal example such as shown at the end. I had to look for awhile, because I found most “simple” threading tutorials a bit over the top for my liking, but taking little bits and bobs from everywhere, I was able to come up with a solution.

Most of it really is just syntactic sugar. The key part about this, is the GobjectThread class. This class starts the MainLoop in a separate thread and after the wx.App.MainLoop is finished, the thread is stopped, too. Luckily, I only have to start and stop the gobject.MainLoop. I can imagine, these sort of things can very quickly become very confusing and cluttered. The only other important thing to note in this code is the close event. It is important to set the Gstreamer elements to gst.STATE_NULL, otherwise there are several Critical Errors thrown, when terminating the MainLoop

Also, as a little side note, while discussing this in the German Python Forum, I was told about Delimiter’s Law. I very often have things like self.player.player.get_state(), which according to Delimiter’s Law is a big “NoNo!”. Essentially, when disregarding Delimiter, too closely knit classes are a consequence. This can make it hard to debug or replace certain parts of the code, because the other classes take too much of the original architecture for granted. Knowing this now, I have a lot more work ahead of me 🙂


import os
import urllib
from threading import Thread

import wx
import pygst
import gst
import gobject

class MyFrame(wx.Frame):
    def __init__(self, *args, **kwds):
        kwds["style"] = wx.DEFAULT_FRAME_STYLE
        wx.Frame.__init__(self, *args, **kwds)
        ## Threading ##
        self.player = GstPlayer()
        # Close Event
        self.Bind(wx.EVT_CLOSE, self.on_close)


    def on_close(self, event):
        # If state not set to NULL, Critical Error occurs on gobject quit
        state = self.player.get_state()
        if state[1] == gst.STATE_PLAYING:

    def __set_properties(self):

    def __do_layout(self):

class GstPlayer():
    def __init__(self):
        # This is almost straight out of the tutorial
        p = os.path.join(os.getcwd(), "tracks", "1. Shaent Blathanna.mp3")
        path = urllib.pathname2url(p)
        self.player = gst.element_factory_make("playbin2", "player")
        fakesink = gst.element_factory_make("fakesink", "fakesink")
        self.player.set_property("video-sink", fakesink)
        self.player.set_property("uri", "file:" + path)
    def get_state(self):
        return self.player.get_state()
    def set_state(self, state):
class GobjectThread(Thread):
    def __init__(self):
        self.loop = gobject.MainLoop() # The mainloop to be separated from wx
    def run(self): # Called on Thread.start()
    def quit(self):
        # Stops the gobject Mainloop

if __name__ == "__main__":
    t = GobjectThread()
    # wxGlade's my Friend here
    # Just basics
    app = wx.PySimpleApp(0)
    frame = MyFrame(None, -1, "")
    t.quit() #End the gobject.MainLoop()

wxPython: XRC and wx.Dialogs

This is a post that arose from a question I submitted to the wxpython user group. I was just not able to call a custom dialog that I created in an XRC file. As a side note, what I find most amazing is, that it is so easy to get in touch with the main guys of the project. In fact, Robin Dunn, the guy who started wxpython, answered my question… I wasn’t surprised when it worked out of the box 😉

Basically, I didn’t understand how to call a wxDialog from an XRC file. I was falling over myself left, right and centre trying to figure it out and at the end I was just plain confused. My answer came in the form of a 2-Stage Creation Process (<– really do read that link) that allows a "load on self" approach. This approach opens up a whole load of new options and makes using XRC really easy. Especially the part about the subclass, I like. Anyhow, I go off in tangents. Ok code. This is how it was done in the end:

class ConfigDialog(wx.Dialog):
def __init__(self, parent):
self.res = xrc.XmlResource("config_dialog.xrc")
pre = wx.PreDialog()
self.res.LoadOnDialog(pre, parent, "ConfigDlg")

As you can see, there is hardly any magic involved. You create the PreDialog (or PreFrame etc.). Load the Dialog and any other flags you may want to add to it, if the need arises. Once that is done you can use PostCreate and everything's peachy. I like it.

wxPython: Inserting an unknown control in XRC to use a custom widget

I’ve been quite busy lately with getting my application done and it has improved by leaps and bounds (I may go into the intricacies of lxml, but I think the tutorials are fairly comprehensive). Most of it was basic stuff that just needed to be pieced together, so there was no real reason to post any code. All of it is documented fairly well in the wxpython wiki and its many, many tutorials (I’m too lazy to mention them this time, just do a google search).

However, recently I came across an issue that annoyed me a little and I finally got round to addressing it. I wanted to have a bitmap button in toggle state (2-state). Unfortunately, wxpython does not allow bitmap buttons to have a toggle state 😦 The answer to this was the use of a PlateButton (Here’s a good introductory tutorial). But since this is a custom widget of the wxpython library, I am not able to use it in XRC, since it is based on wxWidgets.

So what to do? After asking many a lovely person on the interwebs, I finally found a satisfactory but not complete answer. The solution lay with the XmlResource.AttachUnknownControl function (Tutorial).

It allows you to enter a placeholder within the XRC file which can be later filled using the above function. The code I used goes as follows:

First the placeholder was inserted with the following code within the XRC file:

This was followed by the insertion of the following code into my python file:

class MyFrame(wx.Frame):
    def __init__(self, parent):
        self.res = xrc.XmlResource("my_xrc_file.xrc")
        self.frame = self.res.LoadFrame("MyFrame")

        imageFile = "/a/path/to/your/file"
        png = wx.Image(imageFile, wx.BITMAP_TYPE_ANY).ConvertToBitmap()

        self.MyBtn = wx.lib.platebtn.PlateButton(self.frame, bmp=png,
        self.PlateBtn = self.res.AttachUnknownControl("MyBtn",
                                        self.MyBtn, self.frame)

There really is nothing exciting about the code in this example apart from the fact that you need to know that the possibility exists. Self.PlateBtn returns a bool so you need to bind your functions to self.MyBtn. Very useful to know this.

So far, I have not been able to affect the platebutton after I initialised it, that is a bit of a downside and unfortunately it looks entirely different to the rest of the buttons. I will probably end up changing all of the buttons to platebuttons, just for consistency. As a consequence, the XRC file is a bit useless, but hey, thats life.