[gst-devel] Why wrapping GLib interfaces?

Murray.Cumming at Comneon.com Murray.Cumming at Comneon.com
Tue Oct 14 02:55:02 CEST 2003


> From: Ronald Bultje [mailto:rbultje at ronald.bitfreak.net] 
> Hi Ramon,
> 
> On Mon, 2003-10-13 at 13:06, Ramón García wrote:
> > You suggest that it is necessary to offer the
> > functionality of deciding inside each different object whether to 
> > expose an interface or not.
> > 
> > Can you post a use case that shows that this is
> > useful?
[snip]
> The name GstInterface, as Benjamin has said before, is 
> probably wrong. It should be called 
> GstInstanceSupportsInterface or GstElementSupportsInterface.
[snip]

I'm not following this fully, but it sound like you are talking about
implementing Ginterfaces per-instance rather than per Gtype.

Please remember that that is an unusual technique so it will lead to
terrible problems for language bindings. For instance, a C++ API is
determined at compile time, not runtime. In this particular case, that means
that we can't decide at runtime whether or not the C++ class inherits from
one of the base classes. I can think of 2 alternative solutions:

1. Error Codes:
The methods of the Interface return FALSE or a Gerror if they are not
supported.

2. Aggregation:
For instance, GtkTreeView has a 
   GtkTreeSelection* gtk_tree_view_get_selection() method.
In theory, if the GtkTreeSelection functionality was not supported, it could
return NULL.

Sorry, if I have completely misunderstood, but this sounded bad so I had to
speak up.

Murray Cumming
www.murrayc.com
murrayc at usa.net




More information about the gstreamer-devel mailing list