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

List:       kde-core-devel
Subject:    Re: State of kdefx
From:       Matthew Woehlke <mw_triad () users ! sourceforge ! net>
Date:       2007-07-30 16:34:18
Message-ID: f8l3ub$7ar$1 () sea ! gmane ! org
[Download RAW message or body]

Mosfet wrote:
> If it's still needed by apps in SVN, (something I believe Matt is working on), 
> it can be added as a dependency for KDE4.0 without breaking the API freeze.

Actually given the number of users I'm more inclined to keep kdefx for 
now but as a static lib, that way we keep SC for now and can remove the 
lib later affecting SC (which would happen anyway) but not BC. Quite 
simply I can't fix everything without help :-). This means fixing users 
in kdelibs only (to use something else or to copy the code), and moving 
KStyle elsewhere (I'm partial to kdeui since there is other code - i.e. 
KColorUtils, KColorScheme - currently in kdeui that is aimed at styles).

I'd also like to kill off KCPUInfo as a library class entirely, as it 
has three users: ksplashx (which my understanding is that ksplashx isn't 
even Qt), krita, and kdefx itself (and gwenview? ...although lxr isn't 
reporting that). Does anyone know if Solid supports checking for 
extension instruction sets (e.g. MMX)? If "yes" ksplashx and kdefx can 
just inherit the code and others can use Solid.

-- 
Matthew
"...anyway, that's my 0.02 toasters"
(with apologies to Niel)

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