Re: gstreamermm option group does not init



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?

Thanks,
Marcus



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]