state of kdefx (again), BC exemption request

Maksim Orlovich mo85 at cornell.edu
Fri Jul 20 03:09:23 BST 2007


> (I'm CC'ing kde-devel, if you have code that you know uses kdefx please
> read and offer comments if you have any.)

I suggest using lxr.kde.org

>
> Casper Boemann and I were talking about KStyle and its various
> deficiencies (and how we can't technically address them any more due to
> the freeze) while working on the Oxygen style, which reminded me of a
> couple of things...

I plan on finishing up some holes in KStyle ASAP, but it should be fairly
extensible. Oh, and it would be nice if you actually notify people who,
uhm, wrote the class and know why it is the way it is, of any issues you
have.

>
> - As I understand, the major reason this library exists is because in
> KDE3 styles could not safely touch kdelibs.

Yes. That's not the reason the classes in the library exist, however.


>
> - The library has, AFAIK, not had any major review, and has things like
> gradient generators that appear to be obsolete in Qt4.

These are hardly a big issue. 99% of KImageEffect OTOH is useless and
probably doesn't even work.


>
> - People (I forget who) had previously expressed a desire to kill of the
> library.
>
> I'd like to make a request to exempt this library from requirement to
> maintain BC in KDE 4.0 so that we have much more time to address the API
> and hopefully ultimately remove the library entirely
 (merging
> functionality we want to keep into kdeui or elsewhere, or possibly
> giving it new life as a more "traditional" KDE library perhaps in a
> different module). The "nice" way to do this is to make the library
> static so that it can still be used but without BC issues.
>
> Thoughts? Other than styles, who is using the library? What parts of it
> are still needed (and what has been superseded by Qt)?

I don't believe this is acceptable. If classes are really not used,
they're easy to cut, and there is no big reason not to make an exception
for their particular case. If they are used, they should be kept either
way.
(Oh, and one can always make a trivial libkdefx.so that forwards to kdeui.
Has been done before with kspell)








More information about the kde-core-devel mailing list