Re: About compatibility in GNOME 2 (was Re: Compatibility stuff)

[Martin Baulig <martin home-of-linux org>]

Havoc Pennington <hp redhat com> writes:

> There is a big difference here.
> 
> You want us to add API to the stable branch to increase compat with
> the unstable branch, so that apps can be "ported" to the new version
> of the stable branch, allowing them to compile against both stable and
> unstable at the same time.
> 
> We are opposed to that, for IMO good reasons which you did not respond
> to that I see. (Well, Owen and I are opposed - Tim agreed with you,
> which you seem to be missing.)
> 
> The issue about gnome-libs HEAD is simply backward compatibility,
> which we have tried very hard to preserve when remotely possible.
> i.e. your mail did not suggest any changes to GTK+ HEAD to make older
> apps easy to port.

Well, I don't think this is so much a difference.

What we want compatibility in gnome-libs HEAD for is to allow people to
easily use their GNOME 1.x application with GNOME 2.0.

I do think what I suggested has a lot to do with compatibility and I wan't
even proposing something completely insane. What I proposed was in the first
place a way to migrate GNOME 1.x applications to a new API. So instead of
directly assessing private fields in a struct, I suggested to provide
accessor macros.

So, if you look at this just from the GNOME 1.x point of view, this isn't
insane or wrong at all, we'll just add some new functions which will you
can use instead of directly accessing private struct data.

I also do not think that this'll lead us into a large amount of GTK+ version
#ifdefs, because if you do this conditionally for a particular GTK+ version
in your application, then you don't need to do it at all.

My idea was more that you require GTK+ >= 1.2.10 in your app's configure.in
and then use the new functions and macros in it. Since GTK+ 1.2.10 will be
binary compatible with 1.2.9, I don't see any negative side effects in
requesting people to update it to be able to use the application.

After this "porting" action, the application will still be a GNOME 1.x app
and work like it worked before on the GNOME 1.x platform.

But since these new macros and functions will be the same than the ones that
are used in GTK+ 2.0, it'll be a lot easier to port the application to
GTK+ 2.0 at a later point.

Now back to gnome-libs HEAD:

There's a lot of code out there which is using gnome_entry_gtk_entry() and
then sucking stuff out of the GtkEntry directly. This won't work in gnome-libs
2.0 any longer and there won't even be a compatibilty function for it.

However, since the right thing is to use the new gnome_entry_get_text() and
gnome_entry_set_text(), I suggested in my porting document that we add these
functions to the stable version of gnome-libs after GNOME 1.4.

This way, people can start porting their GNOME 1.x applications to use
gnome_entry_get_text() and gnome_entry_set_text() which they'll have to do
anyways when they port it to gnome-libs 2.0. But people can do this in the
GNOME 1.x version of their application, so they don't need to worry about
gnome-libs 2.0 at the moment.

It'll just ease the final migration to gnome-libs 2.0 a lot if people are
already using gnome_entry_get/set_text() in their GNOME 1.x applications.

This won't add any conditionals to any piece of code, this will remove
conditionals and it'll also decreases the differences between the stable
branch and the HEAD once it has been branchen.

Even if people make branches in their applications like you suggest, keep
in mind that once you have a branch, you have to keep track of changes in
both trunks and you need to merge stuff etc.

It'll make things a lot easier if you first port your application to use
these new macros and functions and then branch it for GTK+ 2.0.

Imagine you branch your application for GTK+ 2.0 and three months later
you're running a diff between the two trunks. It'll make a big difference
whether that diff changes stuff at 10 or at 326 different locations in the
code. And when you ever need to merge a particular change from one trunk
into the other, it'll even more make a difference whether you have 5 or 326
changes.

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