Trying to undersand g_signal_connect()

[Enrique Ocaña González]

El jueves, 3 de noviembre de 2016 13:44:05 (CET) Enrique Ocaña González 
escribió:

Sorry, there are some mistakes in the previous email. Corrections in *bold* 
below:

> The 3 parameters of the signal callback, as shown in [2] are:

- GstElement: The object which received the signal. Who is creating a new
  pad? The demuxer. So the demuxer will be this element. In the particular
  code of the example this info isn't needed, but in other contexts it would
  be. For instance, if you register a callback on several different elements
  to just log the creation of pads, you would be interested in knowing which
  element created the pad. In the specific case of the example we register
  the callback to only one element, so we already know that it will always be
  the *demuxer*.
- GstPad: This is the pad being added (to the demuxer element).
- gpointer user_data: This is kind of a "context", or "whatever the
  programmer thinks is needed for the callback to do its job". If the
  callback was a logger, this parameter could have been null. In this case,
  what this callback wants to do is to link the created *demuxer* pad (2nd 
  parameter) with the *decoder*. How do we get a pointer to the *decoder* from
  inside the callback? Using a global variable? That's not very elegant nor 
  scalable (in a scenario with several *decoders*). The best way is to pass a 
  pointer to the *decoder* as "context" when registering the callback. We 
  could also have passed a pointer to the decoder sink pad, or a pointer to 
  the whole pipeline and perform a search for the decoder using 
  gst_bin_get_by_name()[3]. There's always more than one way to do it.

-- 
Enrique Ocaña González