Making kdefx static

[Allen Winter]

On Friday 03 August 2007 6:39:21 pm Maksim Orlovich wrote:
> > On 03.08.07 16:48:13, Allen Winter wrote:
> >> I believe the earlier discussion on this issue, as shown below,
> >> is what we should do.  Note that you do not have an
> >> exemption to put in an entire new subsystem; rather
> >> an exemption to remove and cleanup in kdefx.
> >>
> >> IOW: trash kdefx in KDE 4.0.  Hopefully, we'll have either
> >> 1) Quasar in a future Qt 4.x release 2) parts of Quasar
> >> in a brand new kdefx in KDE 4.1+
> >>
> >> Yes, this might mean that some apps have to
> >> regress on some features.  I guess.  But, it is a .0.
> >> Or, those apps can temporarily copy over the kdefx
> >> code to their local source.
> >
> > Hope you are aware that this is a quite huge undertaking and we're
> > talking about pretty core apps, like the background kcm, koffice parts,
> > the thumbnail slave, okular, kopete for just KImageEffect. No I have no
> > idea how hard it is to port away from that class, but there are 660
> > references, so unless this can be done with a script I doubt thats
> > doable in the current time frame for KDE 4.0. KPixmapEffect seems to be
> > used about the same amount.
> 
> The thing to understand about KImageEffect is that it has a small number
> of largely used functions, and a large number of barely used ones which
> don't work too well. IMHO, the former ones should stay --- what's the
> problem with them? ... And removing them because someone is promising a
> super-fancy image framework is just silly. The later should probably go,
> of course.
> 
Yes, by all means keep the good stuff.
I was under the impression that all of kdefx was "sub-optimal".

-Allen