trinity-devel@lists.pearsoncomputing.net

Message: previous - next
Month: February 2012

Re: [trinity-devel] 01 February 2012 Meeting Notes

From: Martin Gräßlin <mgraesslin@...>
Date: Wed, 01 Feb 2012 23:42:48 +0100
Am 01.02.2012 22:57, schrieb E. Liddell:
> The main problem I'm seeing is kdelibs, which *is* a kwin dependency
> as far as I
> can tell, and which wants to drag in strigi and a bunch of other
> unwanted-by-me
> cruft ranging from phonon to consolekit.
These are all issues going away with KDE Frameworks 5 which we can 
expect the first release out in this year.
>  Either all references to
> kdelibs that can't
> be replaced with tdelibs would need to be scrubbed from the kwin
> code, or a small
> kdelibs-subset containing only the functions vital to kwin would need
> to be created.
> Without knowing the code, I can't say whether that's possible or
> not--presumably,
> Martin can tell us.
It is possible to build such a kdelibs-subset. That was my idea for "Qt 
only kwin". What we need is KWindowSystem which actually belongs to KWin 
but is for historic reasons part of kdelibs. It will also become an 
independent library in Frameworks 5.
>
> If we're going to include kwin in Trinity, we have to cut it down
> those of its
> dependencies that aren't used by anything else to at most 2-3
> smallish packages,
> regardless of what those packages are, IMNSHO.  Concentrating on
> akonadi/strigi/nepomuk is a red herring.
I quite agree that buzzword bingo is the wrong approach ;-) We have not 
many dependencies and I am interested in having a branch with few 
dependencies (also for other parties than just Trinity). But as I wrote 
in the last mail: I decided to delay it till we are based on Frameworks 
5. For Trinity it might be easier as things like kDebug did not change 
between kdelibs 3 and 4.

Cheers
Martin