Re: gstreamermm option group does not init

[José Alburquerque <jaalburquerque cox net>]

There are some things here that I think might need clarification so I'll 
try to clarify as best as possible:

Marcus Brinkmann wrote:
> It is my understanding that using the Gst option group together with
> glib's option parser will automatically cause all necessary
> initialization in Gst.  This is what the documentation of the
> get_option_group method says

I don't think this is exactly right.  Here's what the docs say 
on get_option_group() <cid:part1.07050600.06080307@cox.net> 
<cid:part1.07050600.06080307@cox.net>:

   Returns a Glib::OptionGroup with GStreamer's argument specifications.

   The group is set up to use standard GOption callbacks, so when using
   this group in combination with GOption parsing methods, all argument
   parsing and initialization is automated.
   ...

If you read carefully, I think you'll see that the word `initialization' 
refers to argument initialization and not gstreamermm initialization.  
If you look at the same C API docs for gst_init_get_option_group() 
<http://gstreamer.freedesktop.org/data/doc/gstreamer/head/gstreamer/html/gstreamer-Gst.html#gst-init-get-option-group> 
you'll notice that this function also does not initialize gstreamer for you.

> Note that the C++ program works correctly if I insert a call to
> Gst::init() with dummy arguments.  I would guess that the wrapper of
> get_option_group() fails to call an initialization routing of the
> gstreamermm bindings layer or something.

No.  Gst::get_option_group() relies on the C API for its functionality, 
(ie. it simply call gst_init_get_option_group() and returns the 
GOptionGroup wrapped in a Glib::OptionGroup).  It does nothing more or 
less than what would be done if its C counterpart is called.

> The core of the complete example I provided is this:
>
>   Glib::OptionGroup m_GstOptiongroup = Gst::get_option_group();
>   m_OptionContext.add_group(m_GstOptiongroup);
>
>   Gtk::Main *kit = new Gtk::Main (argc, argv, m_OptionContext);
>
> This should implicitely do whatever Gst::init() does as well.  In
> particular, it should register the type wrappers and what not. 

No.  None of the C API that the above API wraps would call gst_init() 
and thus their C++ counterparts should not "initialize" gstreamermm 
(call Gst::init()) either.  Gst::init() not only initializes the wrapper 
system, it also initializes gstreamer (by calling gst_init()).  In the C 
API calling gst_init() would be necessary so Gst::init() takes care of 
this and initializing the C++ wrapper system also.  A C program can thus 
be easily translated to C++ by maintaining this consistent parallel.

> In C, the core of a corresponding working example is something like
> this:
>
>   GOptionContext *option_context;
>   GnomeProgram *program;
>
>   g_option_context_add_group (option_context, gst_init_get_option_group ());
>   program = gnome_program_init (PACKAGE, VERSION, LIBGNOMEUI_MODULE, argc, argv,
>                                 GNOME_PARAM_HUMAN_READABLE_NAME, PACKAGE_PRETTY,
>                                 GNOME_PARAM_GOPTION_CONTEXT, option_context,
>                                 NULL);
>
> The C program does not call gst_init or friends.  This works just fine.
>
>   

I really appreciate your input, but I sincerely must insist on an 
*actual* equivalent C program to look further into this.  Thanks for 
your input.

--
José Alburquerque
jaalburquerque cox net