RE: [gtkmm] Questions and information

[Murray Cumming Comneon com]

> From: Chris Vine [mailto:chris cvine freeserve co uk] 
> On Wednesday 25 June 2003 7:52 am, Murray Cumming Comneon com wrote:
> 
> [snip]
> 
> > The API stability policy of gtkmm is directly inspired by 
> that of GTK+ and
> > GNOME. You are just arguing about when the API breaks 
> should happen and
> > what version numbers we should use. You do realise that 
> there is going to
> > be an API-breaking GTK+ 3 eventually, and an API-breaking 
> set of GNOME 3
> > libraries.
> 
> [snip]
> 
> This is the nub of the matter.
> 
> Maintaining a library requires striking a balance between not 
> unnecessarily 
> breaking API and so putting the burden on software writers of 
> rewriting code 
> on the one hand, and enabling those library improvements to 
> take place which 
> require an API-breaking change (most do not) on the other 
> hand.  I do not 
> think the balance with gtkmm is right; you think it is.

But it's just a question of time. Why is 2 years better than 1.5 years
between API branches (to pick some time periods out of the air)? I'm fairly
convinced that your main problem with this is just that we are not doing
_exactly_ what GTK+ is doing. And our answer to that is that we are C++ and
that is a different language.

>  I 
> agree there had to 
> be breakage between 1.2 and 2.0, although I think it was much 
> greater than it 
> need have been.

The major breaks were the lack of support for deprecated and broken widgets.
But
1. You did not offer to work on the deprecated widgets. Neither did anybody
else. Nobody was stopping anyone from doing that. Nobody thought it was
important enough to work on it or pay someone to work on it. That's an
undeniable reality.
2. GTK+ did break some widgets such as GtkList and GtkText. They were
broken. It wasn't our fault.
3. The replacement widgets, such as GtkTreeView and GtkTextBuffer, were
significantly different (because they were signficantly better). Again, not
our fault.

You might think that little things like the use of a signal_ prefix were
your major annoyance, but they were actually quite easy to fix, and I think
people like the clarity of the new API and are generally glad that we worked
hard to fix as much as possible given that we were making changes anyway.

But anyway, it's very boring and unproductive to talk about gtkmm 1.2 ->
gtkmm 2 porting now. You have already heard me say several times that it
won't be anything like as bad for gtkmm 2.2 -> gtkmm 2.4.

> Once both gtkmm 2.4 and Gtk+ 2.4 come out, a distributor 
> wanting to support a 
> wide range of code using gtkmm (assuming that a wide range is 
> available) 
> would soon need to ship:
> 
> (i) gtkmm-1.2,
> 
> (ii) gtkmm-2.0 or 2.2, depending on which of these, if any, 
> works against Gtk+ 
> 2.4 

gtkmm 2.2 should work with GTK+ 2.4 because they promise to make no API/ABI
breaks, as you keep telling us. So there's no problem there. (In reality
they did secretly break API/ABI between GTK+ 2.0 and 2.2, which only hit us
because we touch almost every part of the API.)

> - if neither do they are stuck because the distributor is 
> not going to 
> distribute Gtk+ 2.2 as well as Gtk+ 2.4, as in the unlikely 
> event of him 
> wanting to do so, I understand that Gtk+ 2.2 and Gtk+ 2,4 will not be 
> parallel installable), and

Yada yada. An imagined problem. See above.

> (iii) gtkmm 2.4.
> 
> I doubt the distributor is going to want to do that.

Erm. Why wouldn't they distribute gtkmm 2.4?

I _believe_ that I'm making myself clear here, but I seem to be repeating
myself a lot. Maybe someone else can explain this all to you better. I'm
always happy to deal with a real-world problem.

Murray Cumming
murrayc usa net
www.murrayc.com