It would probably be best to fix gstreamer. We had to fix gtk and GNOME
> -----Original Message-----
> From: MHL.Schulze@... [mailto:MHL.Schulze@...]=20
> Sent: Donnerstag, 13. M=E4rz 2003 16:32
> To: Cumming Murray (COMNEON Linz)
> Cc: gstreamer-gstmm@...
> Subject: get_type() madness (was: Building gstmm)
> Am 2003.03.12 12:06 schrieb(en) Murray.Cumming@...:
> > > I added some files I wrote over the past two days. They use=20
> > > _CLASS_BOXEDTYPE[_STATIC]. They almost compile but there are=20
> > > problems with the GTYPE system and a gstreamer c=20
> structure is hidden=20
> > > in the source files which doesn't work with=20
> > > :-(
> > In general, it's a good idea to look for something similar=20
> in gtkmm.=20
> > We have solutions for some of these problems. Sorry, I=20
> can't be more=20
> > specific right now.
> Well, time to get more specific:
> It seems that in gstreamer many ..._get_type() functions=20
> gtkmmproc takes for granted are missing. This is very nasty because
> a) _WRAP_ENUM doesn't work. E.g. compiler error for "make object.o":
> object.cc: In static member function `static GType
> object.cc:284: `gst_object_flags_get_type' undeclared (first=20
> use this function)
> b) _CLASS_BOXEDTYPE doesn't work. E.g. compiler error for=20
> "make props.o":
> props.cc: In static member function `static GType=20
> props.cc:61: `gst_props_get_type' undeclared (first use this =
> Instead of the ..._get_type() functions there are macros like=20
> "GST_TYPE_PROPS". Can we make gtkmmproc use these macros?=20
> Shall we copy the _WRAP_ENUM, _CLASS_BOXEDTYPE, etc.=20
> definitions and adapt them for our use?
> From: MHL.Schulze@... [mailto:MHL.Schulze@...]
> Am 2003.03.13 16:36 schrieb(en) Murray.Cumming@...:
> > It would probably be best to fix gstreamer. We had to fix gtk and
> > GNOME sometimes.
> Why? Is there a rule that there must be a function named
A de facto rule, yes. In general, things should be GTK+-like. I think that
gstreamer was written in the GTK+ 1.2 era and the developers are still
learning about GTK+ 2.
In general, these fixes might be characterised as "registering enums and
structs as GTypes".
> instead of a macro called
> GST_TYPE_PROPS()? Or do you mean we should try to change the
> API so that it fits our needs better (which I can't call "fix")?
Am 2003.03.13 16:36 schrieb(en) Murray.Cumming@...:
> It would probably be best to fix gstreamer. We had to fix gtk and GNOME
Why? Is there a rule that there must be a function named
gst_props_get_type() instead of a macro called GST_TYPE_PROPS()?
Or do you mean we should try to change the API so that it fits our needs
better (which I can't call "fix")?