On Monday 13 February 2012 14:21:19 Timothy Pearson wrote:
On Monday 13 February 2012 15:01:18 Robert Xu wrote:
On Mon, Feb 13, 2012 at 14:53, Martin GräÃlin mgraesslin@kde.org
wrote:
Sure, as I mentioned all commits would not pass review, hardly anyone
is
only close to correct. You are not a window manager developer - that's nothing bad. Hardly anyone is actually developing window managers. It took me more than a year to understand KWin. It is no surprise that
you -
given the amount of code you have to handle, are not able to properly develop it. Think about that we develop the window manager in a peer reviewed style and hardly any commit just enters the tree. Also we
have
hundreds of developers testing our code right from the day it enters master, have thousands of beta testers and much much more
infrastructure
to handle the development of critical code pathes.
That's why it would be important to switch to KWin. It would seriously improve the quality for your users and as it has been stated here more than once, that's what you care about :-)
Martin, please hear my request:
Instead of telling us how great KDE's infrastructure and community is compared to ours, please give us information that can further our development, such as bugs and code snippets. For instance, you have not told us how our code can move in the direction that could possibly bring us into compat with KWin.
that's quite simple: rm -rf twin, git pull kde-workspace
You cannot get twin even close to KWin due to lack of manpower. I have written it before, I say it again: the KWin developer community is larger than the Trinity developer community. In 2011 we had more than 800 commits by 49 individual contributors and fixed ~200 bugs, some of them present since KDE 3.
If you want to get a superb window manager get in touch with us to help tailor KWin for your needs. I offered you several times a separate branch were Trinity specific patches could go. Making KWin compile standalone is something I personally would consider as useful. This is way more efficient and useful than trying to develop twin.
Our community is small and I find it very sad to see commits done to an outdated fork. Seeing duplicated work by fixing bugs again. Seeing users still getting bugs we have fixed years ago. This makes me really, really sad.
Cheers Martin
I outlined the steps to replace twin many, many times. I need to be sure that nothing will break, and that means that for now twin has to stick around. I will need to see support for some of the twin-specific features (i.e. decorated modal system dialogs), and will leave it up to you to handle the specific implementation under kwin4 if you wish.
given your changes to the twin source base I consider this as joke - to be honest. To come here with quality control, while you don't have any for you own. That's a very bad joke and reads to me like "I don't want it and make up an argument that it won't happen". If that is the case: say it than I walk away and let you work for your own.
Any Trinity specific changes have of course to be done by Trinity developers. That should be as simple as putting your commits into the branch - the commit won't apply cleanly, but manually that's possible. I cannot do them as I don't know what Trinity needs and I will never ever install Trinity.
However, twin will NEVER be completely deleted. Why? I don't like relying on an upstream project (KDE) that has a history of seriously breaking things in new releases (history is history and cannot be changed). We need something to fall back on if kwin turns out to have serious problems (e.g. on certain graphics hardware), even if twin's codebase is never touched again.
This is ridiculous. Do you seriously think that we don't take care of ensuring that it does not break on some hardware? Do you think that Trinity will spot severe bugs the KWin team has not found for their millions of users? Are you aware of all the steps we have to ensure that never again a driver will fail KWin? About the fact that we have five different compositing modes? * OpenGL 2 * OpenGL ES 2 * OpenGL 1 * XRender * no compositing That KWin is able to choose the right backend based on the hardware and driver the user is using? That KWin can disable compositing if it notices that things go wrong?
Does this make sense? Do you fundamentally disagree with some part of it?
yes I have as outlined above. If you want to use KWin use it, but stop the fork and no demands to our development team. We have enough to work without taking care of Trinity development. If I offer you help accept it in the way I offer it, but not by demanding futher things.
Cheers Martin