Removing kimageeffect

[Maks Orlovich]

On Wednesday 11 May 2005 03:17 am, Zack Rusin wrote:
> Hey,
>
> another heads up.
>
> I want to remove KImageEffect. Well, maybe not remove, more move and
> refactor (where refactor mostly == remove ;) ).
>
> In no particular order:
> 1) kdecore shouldn't depend on QtGUI or UI classes,

Worthy cause, but is unlikely to be all that simple. 

> 2) kdefx needs to depend on QtGUI,
> therefore
> 3) kdecore shouldn't depend on kdefx
>
> So kdefx should be compiled after kdecore.
> Besides we should restructure kdefx. What is kdefx anyway? Image
> effects? cpu detection? style stuff? Lets try to clear this up. I'd

The intent is style stuff --- it was created in 3.0 as there were difficulties 
in linking styles to kdecore[1]. However, the creation was done at class 
granularity, and there are very few methods that are used from there (besides 
the whole KStyle class) --- basically things like gradients and a couple of 
image blend routines. The image blend routines might not even matter, as they 
were there for the transparent menu stuff, and "the plan" has always been to 
dump the hacks in favor of requiring Composite in KDE4 --- can I trust you to 
make it fast enough for that? ;-). As for gradients, they're still nice to 
have even with Arthur, since they can do things like dithering, for 16 bpp, 
and  the API is much simpler. 

The CPU detection is there for the now-disabled-as-they're-buggy asm routines. 
Some of the other stuff in the lib is really an odd smattering too -- e.g. 
kDrawUtil, etc. It may be worth lxr'ing this stuff to see if any things are 
single-use, and hence dumpable into apps. 

The only true dependency I know of between kdecore -> kdefx, BTW, was[2] 
KStyle::defaultStyle, and there is no reason for it not to be 
KApplication::defaultStyle or such. 


> like to remove KImageEffects from kdefx and put it into
> libkimageeffects. Then split image effects into a couple groups.
> Ideally I'd like to have basis that all the image manipulation apps
> could reuse. Basically I'd like it to become our version of OSX
> CoreImage lib.
> Unless someone has good reasons why I shouldn't do that then I'll do it
> before the end of the week.

Perhaps kimgio should be a part of such a lib, too? hmm, it relies on KSycoca, 
though.

Anyway, whatever you do, though, please check whether kstyles/keramik still 
compiles ;-)


-Maks

[1] Largely because ld.so sucks. 
[2] Well, I didn't add the method to KStyle4, and danimo commented out the use 
in KApp.