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

Stephen Kelly steveire at gmail.com
Wed Feb 9 22:07:42 GMT 2011


Albert Astals Cid wrote:

> A Dimecres, 9 de febrer de 2011, Stephen Kelly va escriure:
>> (Creating a new thread)
>> 
>> Albert Astals Cid wrote:
>> > A Dimecres, 9 de febrer de 2011, Stephen Kelly va escriure:
>> >> You seem to be
>> >> challenging the idea that less internal dependencies in kdelibs is a
>> >> good thing, but I think that's for a separate thread anyway.
>> > 
>> > Not sure if Christoph does, but i do, less internal dependencies is a
>> > bad idea as it will lead us to either less functionality or repeated
>> > code.
>> 
>> How so? The libraries that are in kdesupport (such as attica to pick the
>> first) could just as easily be in kdelibs. If it was in kdelibs, would
>> you object to moving it out? What loss of functionality or repeated code
>> would occur if attica was moved out (imagining it was in to begin with).
> 
> Of course attica won't lose any functionality becuase it is Qt only
> already. But if attica had been designed to be a KDE library and not as a
> Qt-only library it would be using KLineEdit instead of QLineEdit, so
> obviously moving it out of kdelibs (which i guess in your world means stop
> using KLineEdit) would be a functionality loss.
> 
> Albert

That depends on where KLineEdit appears in kdelibs and where attica appears. 
The library KLineEdit is in, kdeui or whatever, could be a Tier 1 or Tier2 
library in the scheme I wrote about on the wiki. Tier1 doesn't mean no QtGui 
or anything like it.

If the attica developers don't actually need the extra completion modes 
provided by KLineEdit, they could make it attica a Tier1 or Tier2 library, 
depending on whether they need something else from kdelibs.

Using KLineEdit instead of QLineEdit does not necessarily provide extra 
functionality if the features it provides are not used.






More information about the kde-core-devel mailing list