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

[murrayc t-online de (Murray Cumming)]

On Wed, 2003-01-15 at 00:48, Chris Vine wrote:
> On Tuesday 14 January 2003 12:48 pm, Murray Cumming wrote:
> 
> [snip]
> 
> > I'm sorry for sounding harsh. I wanted to point out that gtkmm is not an
> > unstable API, because not everyone knows how disciplined we are.
> 
> [snip]
> 
> But Murray, for those who have to rewrite code, it is an unstable API (but as 
> you have explained, not an unplanned or undisciplined API).

No, it is not. gtkmm 1.2 is stable and gtkmm 2.0/2.2 is stable. You can
not say that it is better for gtkmm 2 not to exist. Any API that does
not have new API-breaking major versions is an API that has stagnated
and which is possibly no longer maintained. Maybe we could discuss
examples to prove my point.

Porting between these stable API versions could have been made easier
with a deprecated-API system, but nobody felt that was important enough
to even create such a project.

> If you develop with Gtkmm and like clean interfaces, you must expect to have 
> to rewrite (possibly significant) parts of your code from time to time.  That 
> is one of the penalties of using a GUI toolkit that does not have commercial 
> considerations at the front of its development.

I completely reject the idea that gtkmm is an unstable API, or that
open-source APIs are inherently unstable. 


> As another aside, I thought it a pity that the Gtk+-2 deprecated widgets were 
> not wrapped in Gtkmm-2.  I think that would have avoided some of these 
> difficulties, but as I am not a contributor to Gtkmm it is not my place to 
> complain.

As I said already, everyone has the choice to
a) Start a gtkmm_deprecated_widgets project.
  (I'm SERIOUS - if this is important to you then start it. If not,
please stop whining.)

b) Pay the core developers to do it for them.

> Those who want a different level of stability have two main choices: they can 
> use cross-toolkit abstractions like wxWindows (does that support Gtk+2?) 
> which does not change API because one of its targets changes, or use a 
> toolkit that has commercial considerations which require it to keep its API 
> more stable (such as Qt).

Qt has major versions, and API breakage too. But not as much, because Qt
has stagnated around it's old extended-C++ concept.

> The disadvantage of the latter is that interfaces tend to become more crusty 
> and obscure.  And whilst Qt breaks code less with its major version number 
> changes than Gtkmm, it still breaks some code.

So you seem to understand some of this.

-- 
Murray Cumming
murray usa net
www.murrayc.com