<html>
  <head>
    <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    Hi Tim,<br>
    <br>
    Now that I have stopped 'worrying about it' and started coding, I do
    have a program that works (although I still have to finish it off
    and may find other problems yet).<br>
    <br>
    I was thinking that my code would be like a Y - and that I would
    either be calling gtk_main() (and monitoring for button presses) OR
    calling g_main_loop_run() specifying my code to handle events from
    the Gstreamer bus watches.  While lying in bed, it occurred to me
    that my main program was going to end up calling gtk_main() (always)
    and that when I pressed the appropriate button, I would then call a
    nested g_main_loop_run() - so no problem.  I can start and stop the
    recording by pressing buttons on the screen, and I can press other
    buttons while the recording is active and life is good.<br>
    <br>
    Ian<br>
    <br>
    <div class="moz-cite-prefix">On 13/01/2014 11:52, Tim Müller wrote:<br>
    </div>
    <blockquote cite="mid:1389613952.1982.3.camel@xps" type="cite">
      <pre wrap="">On Sun, 2014-01-12 at 12:21 +0000, Ian Davidson wrote:

Hi Ian,

</pre>
      <blockquote type="cite">
        <pre wrap="">I have realised that the documentation says that calls to
g_main_loop_run can be nested - so my fears are probably groundless.
</pre>
      </blockquote>
      <pre wrap="">
Not sure where you're stuck right now, or what's unclear.

gtk_main() calls g_main_loop_run() internally, so if you have a Gtk+
application and a gtk_main() call in your code, then you don't need to
do anything else for GStreamer bus watches to work.

Which 'two bits of code waiting' were you refering to?

 Cheers
  -Tim


</pre>
      <blockquote type="cite">
        <pre wrap="">On 11/01/2014 11:58, Ian Davidson wrote:

</pre>
        <blockquote type="cite">
          <pre wrap="">I have taken a break from programming over the festivities and have
now turned my thoughts back to my program.

With my GStreamer console based application, the program's main
'lined up all the gstreamer elements', set the ball rolling, and
then went to g_main_loop_run which waited for interesting signals. I
realise that there was a lot of multi-threading and other clever
stuff going on, but what I had to write was impressively simple.

Then I turned to look at my GUI interface and chose GTK as,
seemingly, the best way to write my code. I notice that the main
program lines up all the buttons I want on the screen, I have event
handlers for when buttons are pressed and then I go to gtk_main() to
wait for things to happen.

My hang-up is that I don't know how to reconcile these two bits of
code waiting. I think that I have read that gtk_main is a wrapper
for g_main_loop_run, so there must be something from there that I
need to incorporate into my main loop. Is there some sample code I
can look at?

</pre>
        </blockquote>
        <pre wrap="">
_______________________________________________
gstreamer-devel mailing list
<a class="moz-txt-link-abbreviated" href="mailto:gstreamer-devel@lists.freedesktop.org">gstreamer-devel@lists.freedesktop.org</a>
<a class="moz-txt-link-freetext" href="http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel">http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel</a>
</pre>
      </blockquote>
      <pre wrap="">
</pre>
    </blockquote>
    <br>
    <div class="moz-signature">-- <br>
      --<br>
      Ian Davidson<br>
      <i>239 Streetsbrook Road, Solihull, West Midlands, B91 1HE</i><br>
      --<br>
      Facts used in this message may or may not reflect an underlying
      objective reality. Facts are supplied for personal use only.<br>
      Recipients quoting supplied information do so at their own risk.
      Facts supplied may vary in whole or part from widely accepted
      standards.<br>
      While painstakingly researched, facts may or may not be indicative
      of actually occurring events or natural phenomena.<br>
      The author accepts no responsibility for personal loss or injury
      resulting from memorisation and subsequent use.
    </div>
  </body>
</html>