Re: Compatibility stuff



Tim Janik <timj gtk org> writes:

> 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.

Conditionalizing something to compile against either GTK+-1.2 or
GTK+-2.0 is a HORRIBLE idea. It's crazily stupid.

You might as well conditionalize to compile either against Xforms or
GTK+-2.0.

GTK+-1.2 and GTK+-2.0 are different platforms. Yes, we've made it so
that its easy to convert from GTK+-1.2 to GTK+-2.0 but that doesn't
mean that you can write code that works against either!

If you are going spend time to port to GTK+-2.0, spend time porting to
GTK+-2.0; don't spend time porting to some weird, half-breed
combination of GTK+-1.2 and GTK+-2.0.

The main reason that you are porting to GTK+-2.0 is to:

 - Take advantage of the features of GTK+-2.0

 - Take advantage of the improved API in GTK+-2.0 that allows
   you to simplify your app.

There is absolutely no benefit to porting to GTK+-1.2.10 which has
some API compatibility macros for GTK+-2.0.

Neither you or your users are going to see real benefits until you
port to GTK+-2.0, and so you've just required them to upgrade their
GTK+-1.2 for no reason whatsoever.

And all the issues which were brought up were in writing new widgets,
and there have been a lot more fundamental changes to GTK+ in this
area that aren't going to be easy to conditionalize - like the
disappearance of GtkWidget::draw.

There is absolutely no way we can or should support conditionalizing
code to compile either against GTK+-1.2 or GTK+-2.0.

Regards,
                                        Owen




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