1 Feb
2012
1 Feb
'12
10:42 p.m.
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