KDE4 Libs components

[Nicolas Goutte]

On Friday 03 March 2006 23:11, Olivier Goffart wrote:
> Le Jeudi 2 Mars 2006 21:05, Aaron J. Seigo a écrit :
> > hi all...
> >
> > whipping up KAutoStart reminded me of something most of you will probably
> > remember this from akademy 2k5:
> >
> > 	http://www.kdedevelopers.org/blog/15
> >
> > has anyone put any thought to what the layout of the "Libs-Components"
> > part may look like?
> >
> > if yes, what are your thoughts?
> > if no, then when can we start discussing this? or rather, can we start
> > discussing this now?
> >
> > i suppose we would aim to work towards a proposal (or set of proposals)
> > to hand over to the TWG to sort out?
>
> Maybe it's a bit late, but I'd like to add my 2 cents.
>
> I fail to see the real interest of separating 'components' and 'framework'
> in two different library.
> Anyway, i see potential problems: we are limiting ourself.

Well, I could be provocative and say that we have asked that glib would be 
split into general classes and classes specific to GTK or GNOME. So perhaps 
we could show the way and do that for kdelibs.

>
> If later we want to modify a class to make it depends of another, we can't
> anymore.

As others have written, that is already the case now. I would not mind to use 
KIO::NetAccess::del in KTempDir::unlink but I cannot. I would also have 
prefered not to have to re-introduce my old gzip class from KOffice in 
kdecore in KDE3, as KDE has already a gzip support.

> (this may happen if we add a global configuration key that change the
> behaviour of a class in the 'components' library.  Or simply if we want to
> share some duplicate code that may appears later)
> We can't move a class to another library after the release or it will break
> the binary compatibility.
>
> On the other side, if someone want to use a class from 'components' in his
> Qt application, ha can take it no matter in which library the class is.

Have a nice day!

>
> --
> Olivier