[gst-devel] merits of dumping glib1

[Andy Wingo]

On Wed, 30 Jan 2002, Baker, Steve wrote:

> I have been waiting for someone to say "thats it, we're not supporting glib1
> anymore". There are many features in glib2 which can't be shimmed (or which
> would be a laborious PITA to do so).  Also there are some hairy differences
> which cause subtle bugs in one build or the other - this makes testing more
> time consuming as everything needs to be checked twice. 

Yes. Let's count the ways:

* our shim breaks every time someone does something new with glib2
features (see the demo-mp3.c in plugins/gst/playondemand, compiles with
glib2 but our macro shim is broken for 1.2, and no one's bothered to fix
it because developers mainly use glib2 now)

* the insane utility of GValue type conversion routines

* auto initialization of parameters according to paramspecs: we can't do
this with the shim

* bounds checking on paramspecs

* REFCOUNTING! this is the big one.

the list does go on. i am tired of gtk1.2. let's get our apps ported so
we have no more excuses.

> The subset of glib2 which has been shimmed is the bare minimum required to
> be useful to us and it will be great when GStreamer can suddenly use all of
> glib2 just by dropping support for glib1.

yup.

> The only reason I can think of for maintaining glib1/gtk1 support is that
> fewer people have glib2 installed.  Since glib2 is stabilising and we are
> still aimed at developers I don't think this argument holds much weight.

Right. if folks really don't want to upgrade to glib2 (for which there
are packages on every major distro afaik), they can stick with our next
release. I'm not really excited about backwards compatibility at this
point, especially when glib1 and 2 are parallel installable.

> So I'd like to think that the only decision required is "what version to we
> remove the shim"

After the next one? That would be right nice.

peace.

wingo.