State of kdefx

[Matt Broadstone]

On 7/30/07, Matthew Woehlke <mw_triad at users.sourceforge.net> wrote:
> 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.
>
No, Solid doesn't report information like this, though it _should_. A
little OT here, but maybe we can get ervin to chime in on what the
plan is in supporting more features like this in Solid, considering
the api freeze. Currently a lot of Solid's information revolves around
its ability to report powermanagement information (which seems to be
what the entire Solid::Processor class is about, among others) and to
handle notifications of plugged devices.

Cheers,
  Matt Broadstone


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