Re: gstreamermm option group does not init

[José Alburquerque <jaalburquerque cox net>]

Marcus Brinkmann wrote:
> At Thu, 19 Jun 2008 15:26:07 -0400,
> José Alburquerque <jaalburquerque cox net> wrote:
>   
> > > > Note that we probably can hook into the GOption stuff if necessary.
> > > >     
> > > >         
> > > I think that would be best.  It must be possible, the question is what
> > > is the simplest solution.  How about something like this:
> > >
> > > class GstOptionGroup : public Glib::OptionGroup
> > > {
> > >   GstOptionGroup (GOptionGroup* castitem)
> > >     : Glib::OptionGroup (castitem) { }
> > >
> > >   virtual on_pre_parse (OptionContext& context, OptionGroup& group)
> > >     {
> > >       Glib::OptionGroup::on_pre_parse (context, group);
> > >       init_pre ();  /* Appropriate refactorization of Gst::init() */
> > >     }
> > >
> > >   virtual on_post_parse (OptionContext& context, OptionGroup& group)
> > >     {
> > >       Glib::OptionGroup::on_post_parse (context, group);
> > >       init_post ();  /* Appropriate refactorization of Gst::init() */
> > >     }
> > > };
> > >
> > >
> > > Glib::OptionGroup Gst::get_option_group()
> > > {
> > >   return GstOptionGroup (gst_init_get_option_group());
> > > }
> > >
> > >   
> > >       
> > This would certainly be ideal, but unfortunately will not work because 
> > both init_pre() and init_post() are not publically declared.  If we 
> > could get GStreamer to make them public, I think this would be a pretty 
> > good solution.
> >     
>
> It doesn't work, but for a slightly different reason.  Using a
> castitem pointer creates a light wrapper that does not have the same
> functionality as a newly created object.  In particular, the
> on_post_parse and on_pre_parse virtual functions aren't even called,
> because glibmm does not register its own parse hooks.  To do so, it
> would have to first get and store the actual parse hooks of the C
> object, and, take this, a GOptionGroup doesn't have any getter
> functions!  So it is impossible to wrap the parse hooks after the
> fact.
>
> If there was a function g_option_group_get_parse_hooks, we could use
> that to get the init_pre and init_post hooks of gstreamer, and replace
> them with our own function that calls the gstreamer functions and does
> some extra work.
>
> However, to really make this work, we also need to know the user data
> for the hooks, which is set at g_option_group_new time.  For this user
> data there is no getter and not even a setter function.  Both would be
> needed to complete the wrapping of the parse hooks.
>
> So, in summary, what's needed from glib to complete this are:
>
> void g_option_group_get_parse_hooks (GOptionGroup *group,
>                                      GOptionParseFunc *pre_parse_func,
>                                      GOptionParseFunc *post_parse_func);
> void g_option_group_set_user_data (GOptionGroup *group, gpointer user_data);
> gpointer g_option_group_get_user_data (GOptionGroup *group);
>
> Always annoying if an interface is not closed under all possible operations. :-/
>
> If this is the way to go, should I go ahead and create bug reports
> against glib for these?  Or is there a smarter way to do this?
>
>   
You can try.  I'm not sure what the result would be.  If submitted and 
they like the idea, I think they might accept a patch.  For now, there 
are a few other things that need attention, but trying to enhance 
gstreamermm by making it deal appropriately with GStreamer's 
GOptionGroup would certainly be nice.

--
José Alburquerque
jaalburquerque cox net