mo85 at cornell.edu
Wed May 11 13:19:03 BST 2005
On Wednesday 11 May 2005 03:17 am, Zack Rusin wrote:
> 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,
> 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. 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
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,
Anyway, whatever you do, though, please check whether kstyles/keramik still
 Largely because ld.so sucks.
 Well, I didn't add the method to KStyle4, and danimo commented out the use
More information about the kde-core-devel