KDE4 Libs components

[Gary Greene]

On Friday 03 March 2006 05:11 pm, 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.
>
> If later we want to modify a class to make it depends of another, we can't
> anymore.
> (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.
>
> --
> Olivier

The main reason for splitting them into different libraries is that then a Qt 
app developer who wants to use a feature isn't tied to the extra stuff in 
kdelibs, since it's pure qt and c++ in these "foundation" libraries. Yes, 
there may rise a case where we want to extend a class that has dependencies 
on both core and foundation, but that just means that we have to engineer and 
plan better is all. I for one will be happy to see this split done as apps 
then can be purely qt if they wish and take advantage of some of the 
foundation classes without pulling in all of kdelibs, thus keepingthe 
footprint of an app down.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 190 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20060303/6500e87c/attachment.sig>