Making kdefx static

[Allen Winter]

On Friday 03 August 2007 2:57:02 pm Matthew Woehlke wrote:
> There are a number of people that want to kill kdefx, for a number of 
> reasons:
> 
> - the code is ugly and (reportedly) doesn't work
> - parts are in the process of being supplanted by Qt
> - it exists partly because in KDE3, KStyle could not be in kdeui
> - the code has, AFAICT, received practically no love in a long time
> - parts do not follow naming convention
> 
> The intent as far as I can see is to replace it with a totally new, 
> well-designed and high-quality lib in 4.1. Since of course 4.1 != 4.0 
> and there are unfortunately a number of users that have not ported away 
> from kdefx, we need to do something to provide for a more graceful 
> transition away than simply removing the library.
> 
> Therefore, I can think of a few options:
> 1. Rename the useful bits K3* and remove what we can
> 2. Make the library static
> 3. Both?
> 
> Option 1 would mean we are stuck with stale (and ugly) code for the life 
> of KDE4. Option 2 means we can yank kdefx later without affecting BC. 
> Option 3 is the same as 2 except that 2 is (or is very nearly) SC, while 
> 1 and 3 require minor code changes for all users (i.e. adding "3" to all 
> uses).
> 
> My preference is option 2. If we can reach a consensus, I will plan to 
> do this either Monday 8/13 (if I can get it done by then, I don't have a 
> lot of available time next week) or else Monday 8/20.
> 
> Note that Allen Winter has already stated that kdefx is exempt from the 
> freeze, and that previous consensus on k-c-d has been to proceed with 
> removal of the library.
> 

Matthew,

I believe the earlier discussion on this issue, as shown below,
is what we should do.  Note that you do not have an
exemption to put in an entire new subsystem; rather
an exemption to remove and cleanup in kdefx.

IOW: trash kdefx in KDE 4.0.  Hopefully, we'll have either
1) Quasar in a future Qt 4.x release 2) parts of Quasar
in a brand new kdefx in KDE 4.1+

Yes, this might mean that some apps have to
regress on some features.  I guess.  But, it is a .0.
Or, those apps can temporarily copy over the kdefx
code to their local source.

> On Tuesday 24 July 2007 7:17:06 am Zack Rusin wrote:
> > On Friday 20 July 2007 06:22:33 am Mosfet wrote:
> > > Hey, I see you all are finally noticing kdefx is broken again ;-)
> >
> > So personally I just feel it makes way more sense to do it properly for
> > 4.1 rather than just put something in for 4.0. It's just not a
> > showstopper for 4.0 and applications/libraries that require some image
> > effect as part of some core functionality can just copy and paste the
> > given effect in.
> > These applications will likely require something very special and instead
> > of trying to frantically get a whole image manipulation framework ready
> > and optimized for 4.0 (at, in my experience, great expense to its API) we
> > can simply give ourselves a little bit of extra time and do it properly
> > for 4.1.
>
> Yes, we are in API freeze mode now.  So the decision is already made for
> 4.0. I believe the plan is to remove most, if not all, of the current kdefx
> for 4.0.
>
> Matthew Woehlke has an exemption to kill what needs to be killed in kdefx.