Re: Libsigc++ for KDE/Qt

[Karl Nelson <kenelson ece ucdavis edu>]

> Karl Nelson wrote:
> > Hello, it has been over a month since I last received a reply 
> > on this subject.  The topic has appeared on LWN and the GNOME
> > sites since that time, and yet I have gotten no requests for 
> > assistance or for the technical information that I have offered
> > to provide.  Thus it appears that at least some people in the
> > community feel that making the switch would be a good idea.
> > Since I have received no requests for changes I will be upping 
> > libsigc++ to 1.0 as is.  (following the release of gtk-- 1.1.0)
> 
> Hmm.. did you ever figure out an easy way to disconnect all slots from
> a given signal?  I was stopped right there when I was evaluating the
> library last month (or so).  Without that feature, the entire
> libsigc++ lib was essentially useless for my purposes.

Yes, actually it got a clear() and empty() method that
next day.  Both methods appeared in the 0.8.2 release.
Thus it should be usable for your project.  (clear removes
all, empty indicated that none are attached.)

The only change which I mentioned which has not happened
is the addition of the Mapped signal.  (Which has a size
of 0)  This was one of the prerequists of converting Qt,
at least in my opinion.  However, it has hit a very evil
snag.  It appears that gcc 2.7.2 to gcc 2.91 contained
a bug that makes anonymous unions generate incorrect
code when dealing with operators.  Instead of passing
the this pointer, the compiler places the unions containing
class. To make matters worse it has a different behavoir
when called from the inside the class then outside the class.
(This bug has nothing to do with templates, but rather
the much more mondane unions, so I did believe it til
I saw it.)

Of course, this isn't really a problem for converting
Qt as signals can only be emitted from inside the class (
the one case that older gcc got right.)  However,
it does prevent the mapped code from appearing in libsigc++
proper until gcc 3.0 becomes more generally used.  I
would be happy to supply Qt equiventent 0 size signals 
on request.

--Karl