libsigc++2 in gtkmm-2.4? (was: Re: [gtkmm] ANNOUNCE: glibmm 2.3.0)

[martin-ml hippogriff de]

Am 01.10.2003 um 09:03 Uhr haben Sie geschrieben:
> On Tue, 2003-09-30 at 23:46, Martin Schulze wrote:
> > Am 2003.09.30 18:30 schrieb(en) Murray Cumming:
> > > *** gtkmm 2.2
> > > 
> > > glibmm provides a C++ interface to glib. glibmm was previously
part of
> > > gtkmm.
> > > glibmm 2.3/2.4 will wrap any additional API in glib 2.4.
> > > http://www.gtkmm.org
> > > 
> > > glibmm 2.4 installs in parallel with gtkmm 2.0/2.2, so you can
install
> > > this unstable library without the risk of breaking existing
> > > applications. This allows
> > > us to break ABI and API, though we will try not to break API
unless it
> > > is absolutely
> > > necessary.
> > 
> > I guess this also means that the transition to libsigc++2 will
have
> > to wait ?!
> 
> "Absolutely necessary" is for us to decide, and nothing happens
before
> somebody does it.
> 
> However, personally, I don't look forward to telling people
> to replace all their "SigC::slot"s with sigc::slot - I was
> thinking of asking you to change that back. And so far I
> don't have a list of big libsigc++2 advantages to show
> people.

Well first of all sorry for answering this late.
As to changing back to "SigC::Slot" in libsigc++2 I must say that I
would really prefer a compatibility header: we changed to small letters
to match the c++ standard and increasing the major version digit of
libsigc++ should allow us to do this. (In fact, I clearly remember you
stating that gtkmm-2.0 would have had small letters for classes and
namespaces if you had known this is the preferred way of the standard
by the time you took over maintainership.)

As for the advantages, I'm afraid I can't think of more than is listed
in the announce emails of libsigc++-1.9.x.
"Technologically superior" might be a proper term to sum it up.

Regards,

  Martin