Proposal: Libsigc++ for KDE/Qt
- From: Karl Nelson <kenelson ece ucdavis edu>
- To: gnome-kde-list gnome org
- cc: kenelson ece ucdavis edu
- Subject: Proposal: Libsigc++ for KDE/Qt
- Date: Thu, 08 Jul 1999 11:39:07 -0700
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
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
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++.
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.
] [Thread Prev