Proposal: Libsigc++ for KDE/Qt

[Karl Nelson <kenelson ece ucdavis edu>]

Hello all,

You may be curious why I posted an anouncement for the latest version of
libsigc++ to the gnome-kde-list, so here is the reason for it.  It may be
possible to use libsigc++ as a replacement for the Qt signal/slot 
system which would benifit both KDE and GNOME project.

History of Libsigc++
---------------------
To give some historical perspective, libsigc++ was once an internal working 
of the Gtk-- widget wrapper for gtk+.  It tried to have all the features 
of the gtk+ system with a C++ flavor.  It connected through proxies to the 
gtk+ system to make it appear transparent where C++ ended and the C object
system.  However, it was a very rough system that was virtually unreadable, 
so I recoded Tero's system into M4 just so that I could read it last 
November.  Arround that time people from projects which weren't using Gtk--
started showing up on our mailling list reporting bugs and sending patchs 
to improve the signal/slot implementation.
  
It seems that that section of code once made more understandable was very
usable.  People had been borrowing the system despite its strange state
for their own projects and with improved readablity were contributing back.
Since we hadn't designed it for use outside our project, we decided maybe
we should go back an do it right based on what the users needed an not our 
own.  So we collected a list of improvements and ideas on how to improve 
the system and recoded it as a seperate framework so that it can be used 
without gtk--.  I sent offers of the Harmony project to see if they wanted
in on design of the system, but never received any feedback.  Qt was 
still in licensing change mode at the time and its license was not
flexible enough for making the changes needed to use our system, so
I did not post KDE project.  With input from Lyx developers, I implemented 
what we had and the end result is libsigc++.  

Since the original code was reported on the usenet as being significantly
faster than the Qt system (by some overblown margin over 20 times.)  
I decided to benchmark the two so that I could at least say in some small
aspect that the Gtk-- signal sytem was a good equivlent of the Qt signal/slot
system which is so widely praised by KDE programmers.  I had assumed since 
I was coding off of a rough description of the Qt signal system allong with 
Hickey's callback system, that Qt would be have roughly the same features 
and thus all I could show is that libsigc++ was a bit faster.  Instead I 
discovered that libsigc++ had totally over shot mark of matching Qt.  Far
less impressive then the speed was the pure flexiblity that libsigc++
had over the Qt system.  (Since I had never actually tried doing more
than compiling the Qt examples before, I really didn't expect such an
outcome.)   

Libsigc++ is still part of the GNOME project and Gtk-- is 
being upgraded to use it.


KDE/Qt and Libsigc++
----------------------
Because of my benchmarks it has attracted the attention of some
of the KDE coders.  After a few email exchanges, here has been some discussion 
between myself and Mosfet about 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.

As libsigc++ is quickly nearing version 1.0, so if there are additional 
features which are necessary for  doing such work now it the best time to
discuss it.  The current version as a portablity far greater that the 
original Gtk-- system and except for features requested by users it 
is as good as 1.0.  Thus now is the time if KDE coders are interested
in using Libsigc++ in their project to put in some input.  

Let me explain what would be the benifits of Libsigc++ over the Qt signal
system.  Libsigc++ is a near direct recoding of the Gtk+ signal system, 
or at least as close as was possible without tying things down to gtk+ or
adding features not meaningfull to C++.  The Gtk+ signal system contained a
number of features that did not appear in the Qt system.  To these features 
a variety of conversion utilities was added to enable transformation of type
from Gtk+ C system to the Gtk-- C++ system.  Then this was coded in such a 
way so as to provide maximum flexiblity to the C++ coder.  The formulation
was optimized to look object oriented and to give meaningful errors.  
(There are faster or prettier implementations, but usablity was our goal.)  

Thus to KDE the switch provides
  *  Non void returns.
  *  Marshallers - a mechanism for gathering up return codes
  *  Automatic conversions - ablity to define conversion from
       const char* to string& in the callback (freeing the 
       user form having to worry about it)
  *  No need for MOC compiler.
  *  No type exclusions in the argument lists.
  *  Global, temporary or classless signals.
  *  Compile time typesafty (if it compiles it runs)
  *  Very good C++ errors and warnings the tell exactly 
     where problems occur.

(more details of this can be found in 
http://www.ece.ucdavis.edu/~kenelson/libsigc++/benchmark.html )

Each of these could of course get a full page description of how much of 
any improvement it is, but I will skip it for now. In any case, the freedom,
ease of use, and speed the library provides would certainly increase the 
usefulness of the signal/slot mechanism throughout the KDE libraries.  
  

Code sharing benifits
---------------------------
There is of course benifits 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.  This would encourage 
join coding and standards adoption in the two projects.  Further, projects 
such a Lyx and Siag which provide multiple interfaces can become much easier 
to port and maintain.  Work done toward improving libsigc++ would improve 
the C++ binding of gtk+ something which is certainly needed. Extensions 
such a signals over CORBA and other planned extensions would be able to 
proceed more quickly with increased interest.  Rapid porting between the
projects can only benifit both.

The work on the GNOME side of the fence to benifit form this arrangement
is simply to get Gtk-- up and running with libsigc++.  


#include <std_disclaimer.h>
------------------------------
There are some pitfalls to this of course.  The support for 0 sized signals 
in libsigc++ is missing as of yet, a necessary piece I am willing to 
contribute if this process is decide on.  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.  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.

I hope this clues everyone in, and I look forward to more discussion
on this matter. 

--Karl