Re: Fixing the Gst::Message classes



Murray Cumming wrote:
On Mon, 2007-12-10 at 19:44 -0500, José Alburquerque wrote:
Murray Cumming wrote:
On Sun, 2007-12-09 at 00:58 -0500, José Alburquerque wrote:
I was thinking of changing the "_CLASS_OPAQUE_REFCOUNTED(Message, GstMessage, NONE, gst_message_ref, gst_message_unref)" line in message.hg to something like "_CLASS_GOBJECT(Message, GstMessage, GST_MESSAGE, Gst::MiniObject, GstMiniObject)". Is this a good approach?
GstMiniObject doesn't derived from GObject, right? So I don't think it
would be a good idea to use _CLASS_GOBJECT().

I'm afraid that we might need a new macro, but you might try using
_CLASS_GENERIC() to see how far that gets us.

I will take care of this if it does turn out to be difficult.

I was thinking of writing similar "wrapping" functionality for Gst::MiniObject as in Glib::ObjectBase/Glib::Object. I thought of taking wrap.{h,c} from glibmm and "modifying" them to work for Gst::MiniObject/GstMiniObject and then modifying Gst::MiniObject to include the "wrapper" functionality of Glib::ObjectBase and Glib::Object. I'm wondering if this would be worthwhile at this time. Would it be?

I guess I'll take a look at this.

If you feel like it. :-) I've looked a bit and started to make some modifications, but if you'll look into it you'll probably have a better sense as to what has to be done. Would you like me to send you the modifications I've made so far?

We won't be able to duplicate Glib::wrap() as it works for Glib::Object
because GstMiniObject lacks things from GObject that it needs, such as
object data and notification of destruction. But we should be able to do
something simpler that will be enough for us.


Absolutely.

-Jose


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