RE: [gtkmm] Questions and information

[Murray Cumming Comneon com]

> From: Chris Vine [mailto:chris cvine freeserve co uk] 
> I think gtkmm should keep step with the Gtk+/gnome policy on 
> API breakage (ie, 
> none in version 2.*).

It would be nice, but it's not the top priority. Maybe you would be more
comfortable if gtkmm 2.0 had been called gtkmm 5.6. It's just a number. You
are also ignoring the fact that gtkmm 2.4 will have almost no significant
API breakage. I think it's ABI breakage that you are talking about.

>  I believe that is the approach that a 
> library which 
> was aimed at the end user and intended for adoption by large 
> projects would 
> do: it is the policy which proprietary toolkits (with which 
> you compared 
> gtkmm in a favourable light) would adopt.  Gtk+ has adopted 
> this policy for 
> the explicit purpose of encouraging more widespread adoption.

Yes, as I have said several times, we also understand and practice API/ABI
stability.

Our logic for creating a new API (maybe you don't like the phrase "breaking
the API") at gtkmm 2.4, was that C++ libraries can not be expected to be as
stable for as long as a C library, because the languages are different. For
instance, you can add or deprecate a function of a C library without
breaking API, but you cannot add a virtual method to a C++ class. We think
that this is not too shocking for C++ coders.

This is the original announcement of the gtkmm 2.4 branch, by the way:
http://lists.gnome.org/archives/gtkmm-list/2003-January/msg00002.html

You have not addressed my point that a new API is not a problem because it
has no effect on your use of the old API. You have not yet mentioned any
practical problem.

> If this policy were adopted, there might also then be a 
> chance that gtkmm will 
> be shipped with Redhat and Suse (when I last looked, Redhat 
> had dropped it 
> entirely, and Suse were shipping only version 1.2, but it is 
> about two or 
> three months since I last looked, so this may have changed).

As far as I know, the specifics of our API stabilities plans have nothing to
do with distro's decision to ship gtkmm. Most distros ship libraries if they
also plan to ship applications that use gtkmm. Of course there are other
reasons to ship a library:
http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=82473

Murray Cumming
murrayc usa net
www.murrayc.com
Remember to use the "Reply To All" feature with mailing lists.