kdefx/blitz options

[Matthew Woehlke]

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

-- 
Matthew
People say I'm going insane. I say, "what do you mean, 'going'?".