On Wednesday 31 August 2005 15:37, Harri Porten wrote:
> > The other aspect was much more controversial as it related to kdelibs.
> > The idea presented was to split kdelibs into the parts that only rely on
> > Qt each (most widgets, some of our kdecore parts) and those parts that
> > are either grouped together to make up KDE's framework and the parts that
> > rely on that KDE framework.
>
> I don't see the point here. Philosphically. I don't see where to draw the
> logical boundary. "KDE libraries use Qt" is what describes our situation.
> That means that every KDE library is part of KDE and depends on "itself",
> ie. KDE. Whether library B (i.e. kdeui) also relies on library A (i.e.
> kdecore) doesn't really matter. A is just another lib that would have to
> be shipped with B as is Qt. The important part is just to make sure that
> core parts are designed and implemented in a portable part to allow for a
> portable base that high level libs can rely on.

The idea is to draw the line on class level, not on library level. And there I 
don't see it as a too difficult to to decide on whether a class is part of 
the framework or just a standalone tool class with no horizontal 
dependencies.

Simon