Integration vs tight coupling (was Re: A Qt replacement for KGlobal::ref and deref)

[Stephen Kelly]

Albert Astals Cid wrote:

> KLineEdit is integrated with KDE, QLineEdit is not, we can discuss this
> all you want, but not using KLineEdit gives your users a poorer user
> experience.

Ok. I'm not sure what that integration is and why it's not possible to have 
a KLineEdit that doesn't depend on KLocale, KConfig, KMimeType etc. Some 
developers decide KLineEdit is not worth it and create a library in 
kdesupport, other developers decide it is worth it and create a library in 
kdelibs. 

I think we should create a facility which is better than kdesupport at 
accomodating those who don't think it's worth it to inter-depend on the KDE 
platfrom, but still want to be part of the KDE community, the KDE release 
schedule, and the KDE brand, and create a library which can be marketted and 
accessible to Qt developers as something useful.

I think that can be done to some extent without losing functionality by (1) 
using different designs than 'share code with inheritance' and do more 
delegation to functionality providing classes instead (2) moving platformy 
stuff 'higher' (the apps still depend on the platform, where the 
functionality you're talking about is moved to).

> 
> Of course in an ideal world, QLineEdit would get all the KLineEdit
> features, but that's not going to happen and we know it.
>

Right. That doesn't mean we have the current situation can't be improved.
 
> Albert