Re: Proposal: Libsigc++ for KDE/Qt

[Kurt Granroth <granroth kde org>]

Hi Karl,

Before I get into the "meat" of this, I'd like to say that libsigc++
is VERY nice!  I'm going to fool around with it in the next couple of
days.. but I'm pretty sure that I'll love it.  Great job!

However, all that said, I am not quite convinced that your idea of
using libsigc++ as the signal/slot system for KDE will or even COULD
work.

There are several major reasons for my reluctance:

> ...the possiblity of using Libsigc++ as a replacement for the Qt
> signal system when the KDE coders make a developers cut of Qt
> following the upgrades for Qt 2.0.

This is a huge assumption -- that we will be maintaining a "kdeqt" or
kqt or similar library.  This by NO means a guaranteed thing.  I will
admit that there is recurring discussions about doing such a thing...
but the signficant drawbacks to this (e.g., users can't use "stock" qt
anymore, merging new features between qt and kdeqt would be a pain,
etc) might be fatal.

> There is of course benefits to the GNOME project for adoption of a
> common mechanism for C++ callbacks between the two projects.  KDE
> libraries that do not use the GUI can then become less tied to the
> Qt toolset.  Thus projects can be ported from Qt to Gtk-- and back
> again easily.[and so on]

In fact, nearly all of the core KDE libs make *extensive* use of Qt.
Far from going away from Qt, we are integrating it even more.  For
instance, we are in the process of replacing nearly all uses of the
STL with their Qt equivalents (Qt is *much* faster and less of a
memory hog).  Qt is much more than a GUI library and it shows in our
libs.

What this means is that even IF we switched to using libsigc++ in
place of the native Qt signals/slots, you would still need to link to
Qt!

> Libsigc++ is very loosely tied to STL because of its Gtk-- origins.
> I have no clue how much of an effect this would have on the process.

Well, as I said, we are moving to rid ourselves of the STL due to its
bloat.  Maybe libsigc++ can be recoded to use Qt ;-P

> Of course, the bulk of the work falls on the KDE codes to make
> changes in the Qt library and the corresponding changes in their
> libraries.  But then, I have already done 6 months of work
> seperating the signal system from gtk-- so the task is considerable
> simpler that it would have been some time ago.  As much of the work
> can be done with a well coded script, it is certainly a possible
> task if there is interest.

This is the core of it -- switching to libsigc++ would involve a
significant amount of work.  I can see how scripts could lessen the
problem (and some macro "wrappers" might allow us to leave some code
as is, if we are smart about it).  HOWEVER, there are hundreds if not
thousands of KDE apps out there -- they will ALL have to change to the
new signal/slot mechanism.

Back again to the Qt issue -- maintaining a forked version of Qt would
likely be a huge pain in the ass.  Changing Qt to use libsigc++ is
probably one of the most drastic changes one could make as the
SIGNAL/SLOT architecture is central to darn near everything.  That
means that any further code merges (and there would be lots every time
Troll released a new Qt) would likely have to be done "by hand" due to
the complexity.

The PITA factor here is so high that there would have to be an
*incredibly* good reason to do so.  libsigc++ is good... but THAT
good?  Hmm...

Also, for all of the advantages that libsigc++ has over Qt signals,
you must realize that Qt signals do the job just fine.  We've done
quite well even with the limitations... the added features of
libsigc++ may well be nice and we might WANT them, but we definitely
don't *NEED* them.

So the only real "killer" reason for libsigc++ would be the possible
interactions between KDE and Gnome libs.  Unfortunately, the benefit
here is still a bit dubious.  If you use KDE libs, you *will* have to
link to Qt -- regardless of whether we use libsigc++ or not.  The
argument could be made that you might as well use the "native" signals
and slots, then.

All that said, I really really like libsigc++.  I think I'll start up
some discussion internally and see what happens.  We might be able to
make this work, somehow.
-- 
Kurt Granroth            | granroth@kde.org
KDE Developer/Evangelist | http://www.pobox.com/~kurt_granroth
        KDE -- Putting a Friendly Face on Linux