Integration vs tight coupling (was Re: A Qt replacement for KGlobal::ref and deref)
steveire at gmail.com
Wed Feb 9 22:40:20 GMT 2011
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
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
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.
More information about the kde-core-devel