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
