13 Feb
2012
13 Feb
'12
8:40 p.m.
On Monday 13 February 2012 14:21:19 Timothy Pearson
wrote:
the
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.
OK, then stop demanding that we replace twin this instant. It goes both
ways! :-)
I don't want to hear any further discussion on this topic. You clearly do
not have a desire to support TDE in the long run, so we will explore kwin
as we have time to do so. In the meantime, I will state emphatically that
twin is nowhere near as broken as you would like to claim, and any serious
breakage will be reported to the TDE bugtracker and fixed like it always
has been for the duration of this project.
FOSS is about choice; I have done my part to give users choice as to which
WM to use, and right now given your attitude I would rather replace twin
with Compiz if I had to rather than to use or rely on kwin.
Tim
On Monday
13 February 2012 15:01:18 Robert Xu wrote:
> On Mon, Feb 13, 2012 at 14:53, Martin GräÃÂlin
<mgraesslin(a)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 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. 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