On Friday 20 April 2012 10:45:43 David C. Rankin wrote:
> On 04/20/2012 06:26 AM, Martin Gr��lin wrote:
> "A 'hostile' fork?", that strikes me as a laughable attempt to rewrite
> history. TDE is a group of good people doing good work trying to support the
> continuation of a desktop they prefer as a 'matter of choice' for their
> Linux desktop. Never forget:
I called TWin a hostile fork and not complete TDE. TWin is a hostile fork of
KWin as the reasons for the TDE fork are - as explained in my previous mail -
not valid for KWin and the maintainer has tried in the past to merge the
products again - without success. As the fork clearly has not the blessing of
the developers it cannot be considered as a friendly fork and by that is a
hostile fork. Furthermore no attempts are done to upstream any changes done to
the fork.
This has nothing to do with "rewriting the history". There has never been a
reason to fork KWin.
<skipping a larg part of bad mouthing the KDE development process which has
nothing to with KWin>
>
> > No, the fact that TWin requires Qt 3 is no reason to have the current
> > state
> > with the hostile fork. Best would be a solution of no fork, but a
> > collaborative friendly fork should be possible, given that KWin and TWin
> > share a large code base.
>
> Here is where you and I agree. Our effort should be focused on a port of
> kde3 kwin (along with all its desktop styles, look and feel, etc.), to the
> Qt4 environment. The problem is there are many shortcomings in Qt4 that
> prevent adaption of the existing code. A glaring example is the column
> widget in Qt4 (such as used in konqueror file manager - detailed view) has
> never been capable of correctly handling column sizing (especially the
> rightmost column) and has failed to provide any consistent persistence in
> column size. That is merely the tip of the iceberg.
this again has nothing to do with KWin. Luckily a window manager does not use
the column widget. Please keep that on topic. KWin has been running well on Qt
4 for more than four years, please keep that in mind.
>
> > = What can KDE do about the fork? =
> > Actually pretty much nothing. The license allows TDE to fork KWin -
> > whether we like it or not. All we can do is force you to change the name
> > and urge you to work together with us.
> But understand, TDE is a project we are proud of that continues to meet the
> needs of those that prefer, 'as a matter of choice', the functionality that
> the kde3 interface provides. After being told (as a community) by kde.org
> "it's my way or the highway - kde3 is dead", you can understand the
> skepticism that many may feel in getting back in bed with you.
which again has nothing to do with TWin as KWin is the direct continuation of
KWin as of KDE 3.5. Please keep this discussion on topic. Whatever you think
about KDE and the desktop of KDE is completely irrelevant when looking on
whether there is need to continue the fork of KWin
>
> However, collaboration and further development benefits everyone. Even if it
> ends in failure, there are many lessons learned and the code, in some
> respect, is advanced regardless.
>
> > = Why do I actually care? =
> > The KWin development team is rather small. I would like to see more
> > involvment inside KWin than to see duplicated work in a fork.
> >
> > Furthermore KWin 3.5 has a very good reputation and is known as rock
> > solid. I see this reputation questioned if the TWin fork is continued
> > without the quality checks performed in the KWin development.
>
> This is a good argument - but it is just that - an argument. A desktop
> either provides sufficient checks to be stable or it doesn't run. Quality
> checks? Recall the official release of KDE 4.0.4?
I cannot remember that KWin 4.0.4 had been unstable (see http://ur1.ca/91qsv).
Please keep in mind that I am writing about the window manager and not about
the desktop shell. The new functionality in KWin back then was disabled by
default. Apart from that nobody cares today about 4.0.
>
> > Lets have a look at the recent patch for TWin called "Mac Like Switching
> > Panel". This introduces a new feature to switch through applications and
> > references an implementation in window maker. To be clear: this
> > functionality has been present in KWin since version 4.4 (I added it). A
> > little bit of coordination here would have prevented the duplication of
> > development.
> This is smart. Martin, this is exactly the type of collaboration that is
> open and welcomed without qualification. To do this we should identify
> those features (current or planned) in TDE that are the same or similar to
> what exists in kwin and make sure the implementations are the same.
> Beginning this now will just ease the transition in the future to Qt4.
That would be a good start, yes. But I want to see more.
> If you and Will have time, please help out. You are correct -- your
> experience as a kwin developer is 'valued' and likely exceeds the combined
> kwin experience of everyone here. There is no replacement for experience to
> help guide development. If there is something that we can do better, please
> let us know.
I'm sorry but I want to see the development of KWin go ahead. I have no
interest whatsoever in seeing the hostile fork of KWin continue. My aim here
is to stop the hostile fork and that means that there is no need to help you
developing TWin. If you want to work on KWin (also for TDE) you are more than
welcome to do so.
>
> In looking to coordinate the development between twin/kwin, one of the first
> helpful undertakings would be to identify those areas in twin that
> can/should be changed or rewritten to work better now as well as work when
> transitioned to Qt4.
don't invest time on TWin! Drop it! Right now!
>
> > How likely is it that a non KWin developer would have spotted this crashy
> > code? How likely is it that you know how to create such a situation? (I
> > know it exactly).
> >
> > It is not surprising that you are not able to add code to KWin which is
> > correct - hardly anybody not knowing the code base is able to do so.
> > That's
> > why we perform code review and help new developers to get the code into a
> > state that it works correctly. We are happy to accept patches from the
> > Trinity team to KWin as well (of course we only accept patches for
> > current master). The important difference is that in KWin there is a
> > quality assurance through the code review by *experienced* KWin
> > developers. This is impossible in TDE as there are no experienced
> > developers for KWin.
>
> Everyone has a right to vent, but if we are going to make positive progress
> going forward, let's just agree to be candid and respectful between
> projects. We are all here to learn and help, but no one is here to be
> insulted.
It was not my intention to insult anyone. I just stated the obvious: you have
no experience in developing KWin. I doubt there is anything to discuss here.
>
> Again, these comments are mine and not the comments of the project. I
> believe that coordination and collaboration is a win-win for twin/kwin
> (pardon the pun), and I look forward to it benefiting the codebase. I agree
> with you that an ultimate transition/port to Qt4 is the future. At present
> Qt3 provides a working and workable toolset for TDE.
You can use Qt3 for all of TDE and just transit TWin to be KWin based on Qt
4/kdelibs 4. This resolves the issue in a very nice way.
>
> What I am most interested in is your thoughts on how best to transition twin
> to kwin. I have thoughts from other kwin devs, but I'm interested in what
> order and how best you see it can be done.
>
> In short -- what do you propose?
1. git rm -rf twin
2. git add kwin
3. call it a day
That is: just do it!
>
> I am also interested in the thoughts of the TDE community on this issue as
> well.
> > Now I'm not writing this mail to blame you for writing wrong code. If I
> > would be "evil" I would sit back, relax and wait to see TDE hit the wall
> > which is approaching faster and faster when crashy code gets added.
> > Remember: one of the reasons for Trinity is the (no longer) bad quality
> > of KDE 4 code. And you even use that in your external communication -
> > such crashy changes might backfire and then you cannot blame KDE.
>
> Why then to you still have to press 'F9' twice to have the folder pane
> appear in 'konqueror --profile filemanagement' every time it is opened??
>
> Yes -- in upstream.
Sorry I don't get what you want to tell me here.
>
> Regardless -- I am in full agreement that the blame-game is unproductive,
> and I again think you miss the point if you believe that the reason for
> TDE's existence is because kde4 is crashy -- for me it's not. For me it
> because I can't stand the kde4 UI. That's why I like twin -- as a matter of
> choice.
That's great: then you can just use KWin. KWin does not have any "UI". It's
all styles and the style of KDE 3 times is still available and currently even
shipped with KWin. We even have multiple theme engines in KWin and we want to
transit the legacy themes to these theme engines in future.
>
> If there is a way to have twin migrate back into the supported codebase,
> then that is worth discussing. If there is a way to benefit and help the
> twin transition to Qt4 while maintaining the look, feel and functionality
> of twin -- let's do it.
how good that there is nothing to do in that case: all the styles are still
there :-) All Plasma integration (what you probably don't like) can be
exchanged with another style and everything else is pure QML.
>
> > I'm here now to resolve this issue about TWin together with you. I want to
> > see the hostile fork go away. From all we see TDE is unable to maintain
> > or even develop TWin. Please accept this fact as it is. It is nothing
> > bad, I needed three years of strong involvment in KWin developer before
> > becoming maintainer and there are still large areas of code blocks where
> > I have no clue about.
> Again, it is not a hostile fork - it is what OSS is all about. When kde.org
> decided to disown kde3, and dropped all support for it, OSS did what it was
> designed to do - it provided for the continuation of what we believe is the
> finest desktop ever created - through a fork to tde. Linus is smiling...
Again I am talking about KWin and not about KDE in general. The fork of KWin
is hostile as the reasons to fork KDE are not valid for KWin.
Please keep this thread on topic. It's about TWin/KWin and not about TDE or
KDE in general. I am only discussing this one application and don't care about
anything else.
Thank you
Martin
Attachments: