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

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

[This is my long reply to a mail on gtk-devel-list where I explain why
 I care so much about compatibility in GNOME 2.]

Hi guys,

just for the record in case we need this again in 6 months:

Owen's mail had Message-ID: <ybe66hkyt9l fsf fresnel labs redhat com>
and is at http://mail.gnome.org/archives/gtk-devel-list/2001-March/msg00204.html.

I'm neither annoyed nor pissed by this mail even if it may sound so, it's
the GTK+ team's legal right to decide that they do not care about compatibility
at all. I just think that we should have "equal rights" here.

I'm really no supporter of this childish "if you don't care about compatibility,
why should I", but let's put this this way:

In the last few months, I tried my best to keep as much compatibility in
gnome-libs HEAD as it was at all possible. Whenever I touched any header file
which was part of gnome-libs 1.x I asked myself "is it really necessary to
change this and what can be done to avoid too much breakage in existing
applications". For features that were completely removed from gnome-libs,
there are compatibility wrappers in libcompat.

Last week, several people raised their concerns about how much API breakage
has gone into gnome-libs HEAD and some of them even suggested to throw away
all of my, Georges and whoever else's work and start again from scratch.

There were several people who offered to help with gnome-libs HEAD during the
past few months, but most of them quickly gave up while they were compiling
all the dependencies that were required in order to build it. One of their
biggest problem was that in order to use gnome-libs HEAD you need to compile
all its dependencies against GTK+ 2.0 while these packages are still targeting
the GNOME 1.4 release so that they won't be ported to GTK+ 2.0 in very near
future.

This lead to the situation that I was maintaining patches for ORBit, oaf, GConf
and gnome-vfs in gnome-libs/patches/ which made them compile against GTK+ 2.0.

Now we're actually approaching GNOME 1.4, but I still don't see that day on
the horizon where the maintainers or ORBit, oaf, GConf and gnome-vfs branch
their packages to support GTK+ 2.0. They're targeting the GNOME 1.4.x releases
and there's also active development going into these packages so that the code
changes from time to time.

Maintaining these patches was a pain in the ass from time to time since nobody
really cared about them, people refused to have their code work conditionally
on both platforms and there were also a lot of code changes both in GTK+ and
also in these packages. I never complained about this and I also never complained
that so few people were helping me with gnome-libs HEAD work during the last
few months.

After a lot of work this weekend, I finally assembled a tarball release of
everything which is required in order to compile gnome-libs HEAD which I was
going to announce very soon this week.

So, we now slowly approach a point where people can actually compile gnome-libs
HEAD because they can get all its dependencies in a tarball release.

Then, last week, that discussion about GNOME 2.0 begun and people raised their
concerns that gnome-libs HEAD is way too much broken, that it isn't compatible
with GNOME 1.x anymore and blah.

As I already said, I'm really do not like this childish "if you don't care
about compatibility, why should I", but now let's put this this way:

If the GTK+ team doesn't care at all about compatibility and even refuses to
put such simple compatibility macros into GTK+ stable which I proposed, then
can you please tell me a single reason why I should support any kind of
compatibility in gnome-libs HEAD ?

I mean, the main reason of a compatibility layer in gnome-libs HEAD is to
allow people to easily use their existing GNOME 1.x applications with GNOME 2.x.

For me, it was very important to get as many people interested in doing
GNOME 2.0 as at all possible since I want to make GNOME 2.x as good as at
all possible. And I cannot do this alone. I need the help and the support and
the feedback from all members of the GNOME community to do this. I need
developer's of GNOME 1.x applications to look at the current GNOME 2.0 code,
to try it out, to tell me what I have done wrong or what I can do better,
to suggest features which they want to have in GNOME 2.0, ....

This is just not going to happen if I force all people who want to help me
with GNOME 2.x to abandon the GNOME 1.x platform to be able to do so.

You cannot really expect that people who're developing an application which
is part of the GNOME 1.x will branch their module just to try out and help
with an unfinished, unstable, not yet really existant GNOME 2.0 platform.
Most of them won't even put a bunch of #ifdefs into their application.

They'll stick with their GNOME 1.x code and make their application as good
as possible in the GNOME 1.x platform instead.

If you guys don't believe me, I can show you a patch which makes Bonobo
compile fine with gnome-libs HEAD. In this patch, you will find three (!)
changes which are required to compile it against gnome-libs HEAD.

To say it again, you need to change three lines in the whole Bonobo code
to make it work with gnome-libs HEAD. You need to type less than 100
characters on your keyboard in to do so.

All the rest of it is GTK+ related.

The patch contains about 500 changes most of them only affecting one or
two lines of code. A short grep showed me that it actually changes stuff
at 326 different locations cluttered up all over the Bonobo source code.

With these compatibility macros in GTK+ I bet that I can put the number of
code locations which need changes down to less than ten or even five.

It's really no big deal making a patch which makes changes at 5-10 different
locations in a module as big as Bonobo. It also won't be that much work to
maintain such a patch and some maintainers may even agree to put such a
patch into their module if it does things conditionally.

I cannot imagine that any maintainer which is not at least 99.99% insane
accepts a patch which adds 326 #ifdefs to their module, especially when
most of these #ifdefs change a single line of code.

So, because you do not seem to care about compatibility in GTK+ at all,
we won't see a Bonobo which will work with GTK+ 2.0 in the next couple of
months.

I will not maintain this Bonobo patch, not even if Michael allows me to
put it into CVS in a branch. I just don't see a single reason why I should
maintain a patch which changes code at 326 different locations cluttered up
all over the Bonobo source code when things can be done with just a few
compatibility macros in GTK+ stable.

I made this patch against a single version of Bonobo just as some kind of a
proof-of-concept to show that things actually work and how much work it is
to port stuff.

Cheers,

Martin

Owen Taylor <otaylor redhat com> writes:

> 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

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