Re: [gtkmm] Questions and information

[Paul Davis <paul linuxaudiosystems com>]

>The problems are I hope self-evident:
>
>(i) People writing large projects do not want to re-write them at unecessarily
> 
>frequent intervals in order to have them compile on a version of the library 
>which is still actively supported, distributed and maintained,
>
>(ii) People writing large or small projects want their project to compile on 
>as many distributions and releases as possible, and not to break on each 
>occasion that a distribution moves to a more recent release of the library 
>(and where there are API breakages, they want to deal with it by a few 
>#ifdefs which pick up version definitions obtained at the configure stage in 
>order to keep a wide user target).

i am entirely with christopher on these points.

the move of ardour (80K lines of GUI code) to GTK+2/gtkmm2 is a
daunting task. it would be daunting enough with just the GTK+2 changes
because we have several custom widgets written in C, and because we
make massive use of Gtk::CList. but its even more daunting because of
all the other API changes that gtkmm2 introduces. even though i know
that they are all good, and thus need to happen at sometime, its not
good enough to just dismiss the impact of the changes with a wave of
the hand. i cannot recommend gtkmm for others to use on long-term
projects when changes on the same scale of gtkmm1.2->gtkmm2 are
potentially waiting for us. as long as you don't show a preference for
API stability, there's nothing you can say that makes it seem unlikely
that such changes will happen again in the future.

moreover, the situation with compatible versions of the libraries is
so impossible to manage that as i've mentioned before, ardour comes
*with* its own gtkmm and that gets compiled and statically linked into
the binary. the idea of getting every user of ardour on a machine with
a correctly compiled version of the correct version of gtkmm is too
much to contemplate. 

maintaining API stability across major versions wouldn't entirely
solve that problem, and truth is, we'd probably still ship gtkmm with
the source, but it would certainly make us more ready to switch to the
next version of gtkmm.

but this is all old hat. gtkmm is a great piece of work, and at
this point, that's as much to do with murray as anybody else.

--p