Re: Compatibility stuff

[Tim Janik <timj gtk org>]

On 8 Mar 2001, Martin Baulig wrote:

> Havoc Pennington <hp redhat com> writes:
> 
> > Martin Baulig <martin home-of-linux org> writes: 
> > > * there's a hell lot of code out there which is using things like
> > >   object->klass, klass->type etc. which is now using GTK_OBJECT_GET_CLASS
> > >   and GTK_CLASS_TYPE.
> > > 
> > >   To ease migration to GTK+ 2.0, I'd like to suggest that we add these
> > >   macros to GTK+ 1.2.x. When we do this, people can start to port their
> > >   existing code to use these new macros when they feel like it without
> > >   breaking it on the GNOME 1.x platform.
> > 
> > We don't really want to create apps that depend on a specific .x from
> > 1.2.x, normally interfaces are not added in the stable branch.  (We
> > added those theme-engine-only interfaces in 1.2.9, but those shouldn't
> > create apps that depend on 1.2.9, so it seemed relatively safe.)
> 
> The problem is that this'll make it very hard to port existing GNOME 1.x
> applications and libraries to GTK+ 2.0 if you still want to have them working
> with GNOME 1.x. You will need to provide a lot of conditionals in your code
> which could be avoided by adding at least these type macros to stable.

i think easing migration is more important than trying to
let the interface age of 1.2 growing. i ported beast at
some point and had to add a couple of those conditionals,
it wasn't very convenient, really.
things are much easier if we supply GObject upwards compat API
in 1.2, and since i think we want people to use 2.0 at some
point, we should make sure that transition isn't uneccessarily
complicated.

re-adding gtk_object_class_add_signals() to 2.0 is not such
a good idea though. rather, if we have 1.2.10 that comes
with GObject compat macros, i could hack it to get rid
of the requirement to call that function there as well.

> 
> -- 
> Martin Baulig
> martin gnome org (private)
> baulig suse de (work)
> 

---
ciaoTJ