changes in ThreadWeaver signals and slots

[Boudewijn Rempt]

On Tuesday 15 May 2007, Thomas Zander wrote:
> On Tuesday 15 May 2007 17:03:29 Andreas Pakulat wrote:
> > On 15.05.07 15:09:43, Cyrille Berger wrote:
> > > > This is binary compatible,
> > >
> > > Not really, as any binary build with the old kdelibs won't work with
> > > the newer, and further more I also think it breaks API freeze, as it
> > > requires a code change in the application.
>
> Creative interpretation of the concept of binary compatibility ;)

Huh? If my binary doesn't work anymore because of a lib change, it ain't 
binary compatible anymore. It's not only just breaking linking or startup 
completely that constitutes the extent binary incompatibility.

> > I agree with Cyrille here, especially as this doesn't give any
> > compilation errors. Also I doubt it would've been a real problem to
> > port the few places that use ThreadWeaver along with the commit
> > (koffice, kdepim, kdewebdev and kdevevelop, according to lxr, 68
> > Occurences of the term threadweaver in those modules).
>
> KOffice (well, just Krita was using signals) is already ported.  Mirko
> contacted us before he committed.

Well... More like, simultaneously. Still it was easy enough to fix for me (I 
hope, haven't tested everything yet). And besides, threadweaver is cool 
enough that I can handle a little inconvenience.

-- 
Boudewijn Rempt 
http://www.valdyas.org/fading/index.cgi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20070515/581eafbc/attachment.sig>