Re: [gtkmm] porting projects from gtkmm-1.2 to gtkmm2

[Paul Davis <paul linuxaudiosystems com>]

>>  I say "fine, I understand your point of view", but there's no need to
>> deny the truth. I wish you could say also "I understand your point of
>> view".
>
>I do. And we have a PORTING document to help people (one that you are
>free to patch). But if someone says that gtkmm is an unstable API then I
>must challenge that untrue statement, because there is a risk that
>someone might believe it.

how about if they say "there were radical changes between gtkmm1 and
gtkmm2, and any reasonably large program that was written for gtkmm1
will probably take a notable amount of work to port to gtkmm2"?

i very much admire and respect and appreciate the amazing amount of
work that you and others have put into gtkmm2, but you can't point to
the ability to have versions 1 & 2 coexist on a machine and say "see,
the API is stable - we just have two different versions of it".
changing all the event signal names for no reason other than it being
slightly clearer what they are - this kind of change doesn't allow me
to conveniently use #ifdef's to handle two the different versions, for
example, and thats typically what i would mean by reasonable but
incomplete API stability.

its not your fault that GTK dropped CLists and CTrees in favor of a
rather baroque but powerful new widget. nobody (i think) has suggested
that any of you did anything wrong here. but the API to
gtkmm-noversion has *radically* changed, and many people will find it
quite a lot of work to port their programs. my own estimate is 2-3
weeks of work for my current main project, mostly because it includes
custom widgets in both GTK and gtkmm.

i'm not suggesting you do anything different next time (if there is
one). please just don't reject our experiences as users so
readily. its OK to significantly change the API, just admit that this is
what has happened. 

--p