[gst-devel] Re: [gst-cvs] jdahlin gst-plugins: gst-plugins/ gst-plugins/sys/v4l/

[Ronald Bultje]

Hi,

On Mon, 16 Aug 2004, Benjamin Otte wrote:
> On Fri, 13 Aug 2004, Ronald Bultje wrote:
> > The only serious complaint that was/is left is that I abuse GObject-style
> > macros. If that's still a complaint, then I propose renaming those macros
> > to GST_SOME_INTERFACE_CHECK() and GST_IS_SOME_INTERFACE_CHECK() and using
> > standard macros for the cast/is macros. That should please everyone, but
> > can only be done in 0.9 because it's API breakage.
> >
> libgstui has a GstVideoWidget with this function:
> gst_video_widget_set_overlay (GstVideoWidget *widget, GstXOverlay
> *overlay)
> This function obiously wants something that is an overlay, because
> otherwise it can't embed it. On the other hand I want to be able to set
> xvimagesink before I set it to READY. And I really don't want a
> return_if_fail because it's not yet READY.
> (FWIW, I currently have an #undef GST_IS_X_OVERLAY, #define
> GST_IS_X_OVERLAY (glib_representation) in an explicit unbreak.h header.

I just told you I'm willing to change these macros and probably will. Stop
complaining please.

> I'm also opposed to GstImplementsInterface because it puts functionality
> for an interface in a totally different location. The check wether the
> functions for interface X are supported, should go into interface X
> itself, not into some layer above. It's not much code to add it to
> each of those interfaces seperately (mixer and overlay, are there any
> others) and it doesn't confuse people implementing interfaces for other
> elements ("Did you add this to the implements_interface function?" -
> "What?") - especially when they implement interfaces that don't need this
> functionality, like say GstTagSetter.

You can put it in the interface, but that's just code duplication. As you
surely know, interface dependencies are similar to object inheritance.
It's the same thing. I considered it cleaned. If you disagree, feel free
to fix it and not break anything while you're at it. I consider it too
much effort at no gain at all (a loss, even, because we start
duplicating code). I don't see why you'd do it. The description of the
interface explicitely states all this (see e.g. the PWG).

Ronald