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

[Havoc Pennington <hp redhat com>]

Martin Baulig <martin home-of-linux org> writes: 
> 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.

That's why we need to BRANCH. It's not that hard. ;-)

Though some people seem to have an aversion to it...

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

GTK requires lots of changes to object/widget implementations. It
doesn't require many changes on the level at which libgnomeui
operates, i.e. simply using an existing widget. So application code
(as opposed to library code) should be simple to port.

This was unavoidable with the move to GObject and some widget system
modifications that are overall for the better (the main changes to
widgets are to delete a bunch of code, such as draw_focus,
draw_default, draw, manual backing store maintenance, manual
background drawing, etc.). If you have concrete suggestions please
give them.

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

Any maintainer who accepts a patch to build against two GTK versions
is insane, even if the number of ifdefs is only 5. It's flat-out a bad
idea. Use a branch.

Re-read Owen's mail; typically the port to GTK 2 allows you to
simplify code a lot, or use new features in GTK 2. There's no point
porting to GTK 2 if you aren't going to use any GTK 2 features, which
you can't do if you continue to work with GTK 1.2.

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

If you have patches to GTK 2 which make it more compatible, we are
generally willing to take those. Again, your patches are to GTK
1.2. We have a long-standing policy against adding API to stable
branches.

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

If you won't port Bonobo to GTK 2, I'm sure someone else will get
around to it eventually. ;-)

But I fail to see why you can't put a gtktransition.h header
containing the two #defines you wanted in Bonobo itself, instead of
waiting for a GTK 1.2.10. It's 2 lines of code - I think it'd be easy
enough to maintain separately from GTK, and then you won't force users
to upgrade their GTK for no good reason at all. A GTK 1.2.10 would
take Owen a week or two of work in addition to forcing users to
upgrade, a gtktransition.h takes you 5 minutes with no user
burden. Which makes more sense?

Havoc