Am 01.02.2012 20:47, schrieb Robert Xu:
> All there:
> https://gist.github.com/1718892
>
> Feel free to speak up should you have an opinion - the door is always 
> open!
Before misinformation about KWin spread, I dare to speak up.

> 17:47:35 <kb9vqf-offsite> Personally I would hate to have to install 
> kwin, which relies on a bunch of other KDE4 libraries and automatically 
> installs that akodani garbage scanner stuff, just to use TDE

Personally I hate statements without checking facts. KWin neither 
requires Akonadi nor Nepomuk. My CI-system has neither one installed. 
But to give proof:

martin@martin-thinkpad:~$ aptitude show kde-window-manager | grep 
akonadi
martin@martin-thinkpad:~$ aptitude show kdebase-runtime | grep akonadi
martin@martin-thinkpad:~$ aptitude show kdebase-workspace-bin | grep 
akonadi
martin@martin-thinkpad:~$

So this should not at all be a problem for Trinity - yeah \o/ :-)

> 17:48:04 <kb9vqf-offsite> kwin4 is highly integrated into kde4's core 
> libraries
> 17:48:13 <kb9vqf-offsite> unless I'm wrong :)
again checking facts first, helps. You are mistaken. Of course KWin 
uses kde4 libs, but nothing so critical that I would not suggest to you 
to use KWin instead of your fork. In fact I did an in dep analysis 
whether we could go for a Qt4-only version just last week. I decided to 
postpone to after frameworks 5 due to many kDebug statements. But apart 
from that the usage is rather small and could easily be ifdefed. I think 
I offered you to use a special branch in kde-workspace and I have a 
CI-system which can ensure that the branch does not break.

> 17:48:48 <eliddell> I find it odd that that KDE dev never gave a 
> concrete example of a twin bug fixed in kwin. Why is it superior?
I find it odd that you question the stating of one of the devs who 
really knows the code. If you are interested in the bugs: our bug 
tracker and version control system is open. Feel free to search :-)

> 17:49:19 <Strangelv> Didn't they fix most of the bugs by starting 
> over with a mostly new slate of bugs?
> 17:49:22 <kb9vqf-offsite> yep
no! We did not start over! The window manager is unchanged - except 
less bugs! We added a compositor which is orthogonal to the window 
manager and of course we introduced bugs there. But we also fixed them. 
At least there are less bugs in KWin's compositor than in kcompmgr used 
by trinity (btw. the developer of kcompmgr is one of the core 
contributor to todays compositor). Feel free to watch my blog where I 
soon will show some stats about the development history since 4.0. It 
shows nicely that the window manager is hardly changed.

> 17:49:34 <kb9vqf-offsite> kwin has a different focus
> 17:49:43 <kb9vqf-offsite> it aims to be a fancy effects type manager
No! KWin has no focus on being a "fancy effects type manager". Yes we 
have fancy effects, because there is user demand, but we have none of 
the fancy effects supported by default.
> 17:50:01 <kb9vqf-offsite> but I can almost guarantee dependence on 
> new Qt4 features
Yes of course we make use of features of Qt 4.7. Why shouldn't we? It's 
a great release and I can only recommend you to make usage of it :-)

If you have questions about KWin please ask, but please don't base any 
decisions on wrong information. Unfortunately none of the statements by 
kb9vqf in regards of KWin has been correct. I have no idea who is behind 
this nickname and I personally don't care.

Once again I can only recommend you to use KWin instead of twin. KWin 4 
is a continuation of KWin 3 and not a rewrite. The KWin team has more 
active contributors than people had been active in your latest meeting 
:-)

Kind Regards
Martin Gr��lin

KWin maintainer