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

[Helmethead <hoshem mel comcen com au>]

Ah what the hell, I'll throw in my 2 long winded cents.. sorry about the long winded part
This will mostly be a summary of what other people have said. Everyone's going around in circles so I feel it's needed :)
BTW my opinion is neither backed up by or cared about by the gtk gods. Most of the stuff I say probably won't be backed up by me in the morning either.

I agree with Owen and Havoc in general, I think you should put your macros in a header file separate from gtk, and someone showed how #ifndefs/#endifs mostly remove namespace worries.

First, there's the reasons not to change gtk 1.2.x.. lets see how well I can articulate this

It's the nature of the task that programmers often have to simultaneously worry about a million things at once, and the art of good programming is in great part about reducing the number of worries. One thing people do -not- currently have to worry about, is whether their code written for one gtk 1.2.x will work with all the others or not. This is guaranteed to work because the gtk people will not allow api changes to the 1.2.x branch, including api additions or subtractions. If they do what you propose, then programmers who write for 1.2.10 have to worry about whether they are using api that is compatible across all 1.2.x, or if their program will require gtk >= 1.2.10 (for example). If they don't worry about that they will probably have unexpected problems that are very inconvenient.

One might say that they could announce in docs that your api is incompatible and what it is for, to make any general confusion negligible, but they could do that for all proposed gtk 1.2 api additions, and soon we have clutter and everybody is confused despite all efforts. That is of course a well understood thing though.. my point is that if my insight isn't going haywire, you seem to think that your changes will not damage compatibility between 1.2 libraries enough to justify blocking them, and you do not seem to acknowledge that such a change would start the nasty trend of clutter I just talked about, the same reason that the "no api changes" principle is not broken at everyone's convenience.

So 1.2.x should not have api changes so programmers and maintainers have less headaches, and any api change is too much api change. Instead you can include a transition helper header file. This also has the advantages that you don't need to wait for gtk 1.2.10, and you don't need to tell your users to upgrade gtk.


The second issue totally clean and separate and having nothing to do with the first, is if you should be doing what you are doing in the first place. You are seeing changing an application from gtk 1.2 to 2.0 as some slight adjustments to the application, mostly just inconsequential api semantics even. If this is the case then making the stable branch forward-compatible with the unstable is a sound idea.

Apparently, moving from gtk 1.2 to 2.0 is a major transition, requiring major reworking of applications to take advantage of it's features. Such being the case, adding forward-compatibility api to 1.2 will complicate things rather than simplify them. If you don't wish to take advantage of it's features then there's no reason to change at all, gtk 1.2 can and will be installed alongside 2.0, and apps that use it will work fine in gnome 2.0.

Things get a bit more complicated when libraries that depend on gtk enter the scene, so I think there may be good reasons for forward compatibility or ability for apps/libs to compile on both gtk versions


In conclusion, use a header file separately from gtk :)

> Well, I'm still waiting for someone to explain me what exactly the difference
> is here. Let's choose the GnomeEntry example here.

With true forwards and backwards compatibility, both situations mean that a program will run correctly on two versions of a library, the difference is whether that program must use the old or new api.

Owen isn't talking about true zen precise backward compatibility. As I understand it, backward compatibility is a high priority for gtk but not one of the highest, meaning they wish that programs written for 1.2 can be converted as painlessly as is possible/feasible to 2.0. This doesn't seem to mix with "gtk 1.2 and 2.0 are entirely different platforms" though :) on that you may want to say "please explain" (as one of our less respected leaders down here in aus would).

> i)  backwards compatibility:
> 
>       A GNOME 2.0 library will work with GNOME 1.x code because it supports
>       the GNOME 1.x API.
> 
>       In gnome-libs HEAD, it's no longer allowed to use gnome_entry_gtk_entry()
>       and to suck things out of the GtkEntry directly, it does not support this
>       API any longer.
> 
>       Instead, there are two new accessor functions, gnome_entry_get_text() and
>       gnome_entry_set_text().
> 
>       So gnome-libs HEAD is not backwards binary compatible with GNOME 1.x.

not precisely, but close, and that's what people want

> 
> ii) forward compatibility:
> 
>       A GNOME 1.x application or library will work with GNOME 2.0 without
>       making any changes.
> 
>       I suggested that we add gnome_entry_get_text() and gnome_entry_set_text()
>       to gnome-libs stable.
> 
>       This would mean that gnome-libs stable would become forward compatible
>       with gnome-libs HEAD (*).
> 
> You guys seem to be concerned about backwards compatibility in GNOME 2.0 and

Not to the point of hampering innovation. That would be evil, that would be Microsoft. er..

> you don't seem to care about forward compatibility in GNOME 1.x.
> 
> Ok, so let me show you ii) implies i) and it's done. Or do I miss something ?
> 
> So, let's assume
> 
> * gnome_entry_get_text() and gnome_entry_set_text() has been added to
>   gnome-libs 1.4.1
> 
> * Application Foo is only using gnome_entry_get/set_text() and not using
>   gnome_entry_gtk_entry() at all.
> 
> * Application Foo is using gnome-libs 1.4.1 and has not yet been ported to
>   gnome-libs HEAD so that it's still part of the GNOME 1.x platform.
> 
> And now let's look at gnome-libs HEAD again. Foo is a GNOME 1.x application
> and it is not using gnome_entry_gtk_entry(). This means that gnome-libs HEAD
> supports all of the API that is used by Foo.
> 
> Conclusion:
> 
> There is at least one GNOME 1.x application X and gnome-libs HEAD is backwards
> compatible with X. Since Foo was any GNOME 1.x application, so ii) => i).
>
> So, what's now the difference between backwards and forward compatibility ?

Your logic is flawed because Foo is not any GNOME 1.x application, Foo is a Gnome 1.x application using 1.x's forward compatibility api. For any application Foo, Foo is compatible with HEAD because Foo was in essence written for HEAD, not because HEAD is backwards compatible. Foo works with 1.x because IT is forward compatible. The two are still different. Backward compatibility demands that ALL 1.x applications work with HEAD, not just the ones written in the forward compat api, so forward compatibility does not satisfy it's requirements.

Hope I have straightened some things out :)


_______________________________________________
gnome-hackers mailing list
gnome-hackers gnome org
http://mail.gnome.org/mailman/listinfo/gnome-hackers