[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: Making kdefx static
From:       "Maksim Orlovich" <mo85 () cornell ! edu>
Date:       2007-08-03 22:39:21
Message-ID: 10973.24.59.195.3.1186180761.squirrel () webmail ! cornell ! edu
[Download RAW message or body]

> 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.




[prev in list] [next in list] [prev in thread] [next in thread]