kdefx/blitz options

[Allen Winter]

On Monday 13 August 2007 11:15:50 am Matthew Woehlke wrote:
> winterz asked me to post an update on what our options are w.r.t. kdefx. 
> So, here we go...
> 
> 1. keep for KDE4
>    + least invasive, least work
>    - stuck with it in KDE4, may become orphaned
>    - code is not in good shape
> 
> 2. replace with blitz
>    + cleaner code, maintained, up to date
>    + porting should be not too bad
>    - stuck with blitz in KDE4, may become orphaned
>    - not allowed by freeze (would have to make an exception)
> 
> 3. remove from kdelibs (move to kdesupport)
>    + allows full removal later (e.g. 4.1), BC
>    + minimal (no?) porting work for apps
>    - may require duplicating code in kdelibs (privately)
>    - kdesupport change, may be freeze conflict?
>    - code is not in good shape
> 
> 4. remove from kdelibs, offer blitz in kdesupport
>    + cleaner code, maintained, up to date
>    + no more kdefx anywhere :-)
>    + blitz can be removed later (e.g. 4.1), BC
>    + porting should be not too bad
>    - may require duplicating code in kdelibs (privately)
>    - kdesupport change, may be freeze conflict?
> 
> Personally I think I prefer 4, although if we really wanted we could do 
> both and let app maintainers make the call. At any rate, options 3 and 4 
> allow us to defer the ultimate fate of our FX library until an arbitrary 
> later point in the KDE4 lifecycle, whereas options 1 and 2 leave us 
> stuck with something until KDE5. (Also I'm not 100% convinced I am not 
> forgetting some other options :-), if so please jump in.)
> 
> In addition, I've already started to prune back kdefx; KPixmapSplitter 
> is very likely going to be removed (possibly today) [1], most of 
> kdrawutil is already gone, and KStyle I plan to move to kdeui today [2].
> 
> 1: http://permalink.gmane.org/gmane.comp.kde.devel.core/44549
> 2: http://permalink.gmane.org/gmane.comp.kde.devel.core/44590
> 
> (Note that the new class proposal in [1] has been dropped; instead the 
> remaining users will be ported to private code.)
> 

I also prefer option #4.

-Allen