Re: [gtkmm] porting projects from gtkmm-1.2 to gtkmm2
- From: Chris Vine <chris cvine freeserve co uk>
- To: gtkmm-list <gtkmm-list gnome org>
- Subject: Re: [gtkmm] porting projects from gtkmm-1.2 to gtkmm2
- Date: Tue, 14 Jan 2003 23:48:30 +0000
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).
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. It is probably for this
reason that even though Gnome-2.2 is shortly to be released (replacing
Gnome-2.0), significant quantities of the Gnome programs people use on their
desktop still use the Gtk+-1.2 and the Gnome-1.4 libraries.
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 a means of reducing the rate of churn, which is important for
large projects (perhaps Gtkmm is not aimed at these), it would be nice to
think that ones code could survive one major version number change without
having to do a substantial code re-write. (I accept, to adapt Lady
Bracknell's remarks in the Importance of Being Ernest, asking for it to
survive two would be asking for too much).
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).
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.
Chris.
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]