This starts to become a dangerous path (Was: New Feature for kdelibs)

[Kevin Kofler]

Thomas Lübking wrote:
> Therefore my suggestion (if opening 4.x even as wrapper linking
> frameworks is no option) would be to compile the features into the
> application requiring it right now rather than forking a library
> because you cannot alter it. (Don't forget: this is about covering the
> time to frameworks, thus temp. bloat can be accepted to a certain
> degree for a better good)

That's not always possible, at least not without forking huge portions of 
kdelibs into the application. (Remember that the main thing the Frameworks 
effort wants to change is exactly that everything depends on everything in 
kdelibs.) E.g. if you need a new way to handle cookies, you can't just add 
that to your application without copying the whole cookie-handling code and 
everything which references it (i.e. probably KHTML etc.), and renaming it 
all to prevent symbol clashes, which is not a scalable approach. Also note 
that distributors absolutely HATE bundled library code.

        Kevin Kofler