On 04/20/2012 06:26 AM, Martin Gräßlin wrote:
Hi all,
I had to see that there is still development going on in your fork of KWin and
I am very unhappy about that. This is something I really want to see resolved,
any development to KWin should happen in KWin, it's such a waste to work on
the same project without coordination.
Let's first recapture the state of TWin:
= Why does TWin exist? =
Because KWin got forked together with everything else from KDE 3.5 to form the
Trinity Desktop Environment (TDE).
= Why has the TDE fork happened? =
The TDE fork existist because of a combination of the following reasons:
* Parts of KDE had to be rewritten in order to be ported to Qt 4
* Early versions of KDE 4.x were lacking functionality compared to KDE 3.5
* Early versions of KDE 4.x had quality and stability issues compared to KDE
3.5
* A general disagreement with some project decisions
* KDE 4.x introduced new technologies unliked by some (e.g. Nepomuk or
Akonadi)
= Do these reasons hold for KWin? =
No! None of the reasons stated above has ever been true for KWin. KWin is a
direct continuation of the KDE 3 version. The codebase did not get rewritten,
the quality of the window manager did not suffer, new functionality got added
as optional addons.
= Is there any other reason justifying the TWin fork? =
Maybe the fact that KWin depends on Qt4/kdelibs4 which is not liked by TDE.
= Is that a reason for a hostile fork as it is at the moment? =
Whoa, whoa whoa.... Martin -- hang on, I think you have the wrong idea
concerning the TDE fork. I am in agreement that there is no reason to
duplicate work and if there is a way to collaborate that helps kwin/twin, then
that is something that should we should do.
Note, these are my thoughts and not the thoughts of TDE. In reading though
your post, I see the good intent and the opportunity for both projects to do
something good, but I was struck by a few of your comments. Now, I understand,
I may not have gleaned from reading the intent you meant to convey, but there
are several point I want to comment on.
"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:
(1) any group of people have an absolute right to fork any OSS project at any
time consistent with any applicable licensing agreements for any purpose what
so ever; and (the way I saw it -- yes I was there)
(2) kde turned kde3 into a bastard child of a desktop, completely disowning
and disavowing the 'old' code in its own fork that went off chasing plasma
eyecandy widgets and a dumbed-down desktop UI that prioritized form and glitz
well above core user function. It did so in a manner that maligned anyone who
voiced an opinion that they preferred the kde3 interface to kde4. (not to
mention the outright hostile responses on the kde mailing list to anyone
mentioning anything to do with kde3 that I 'personally' was on the receiving
end of)
The Berlin meeting in March 2005 held largely in secret with 15 or so in
attendance marked the radical departure of kde away from kde3 and toward an
'experiment' to create a completely new desktop built around the Oxygen,
Marble and Plasma projects. Those 15 at Berlin, decided on a fork that
ignored, to a large extent, the needs and desires of the kde community
essentially usurping a community project to satisfy the whims of a few to
experiment with what they wanted in a desktop notwithstanding the 'choice' of
the community.
A fine goal to be sure, but beginning in 2008, it was to give us all a lesson
in how NOT to manage an OSS project by releasing the first 'official' non-beta
release of KDE 4.0. The joke (on the kde user base) was that 4.0 was barely
alpha-quality code when 'officially' released that lacked nearly all usable
features of kde 3.5, had horrible crippled implementations of core desktop
tools (konqueror file manager -- relied upon for years by users), and was in
short -- was unusable. While at the same time pressuring all major Linux
distributions to discontinue kde3 by halting all support for the 'old' version
(kde 3.5.10 released only months earlier)
Four years later, kde4 still struggles to provide a usable replacement for the
kdePIM.
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.
While I agree that ultimately, this port to Qt4 is the future for TDE, this
type of limitation makes focusing on the port now an effort in futility. I'm
sure if these problem were coordinated with Riverbank, they could be overcome.
But, as with anything when relying on a 3rd party toolset, the timing of when
this will take place is something that is out of our control.
It comes down to this. The existing TDE codebase, built on Qt3/TQt3 allows for
the continued development of TDE with its traditional look and feel and
without the additional layer of uncertainty that comes with using a toolset
that is still in a state of flux. Continuing TDE development on TQt3 is
something that is doable now -- not at some faroff time in the future whenever
Riverbank decides to fix the shortcomings with Qt4 that will allow a port to
function properly on that toolset.
= 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.
We agree. We have all licked our wounds from the battle of the direction kde
should take and are willing to do what is best for both desktops, TDE and KDE.
There is no question that if what you are offering is a willingness to embrace
effort to help bring TDE back into KDE as something like "KDE-Classic" then it
makes perfect sense from a resource standpoint to see if we can find
common-ground and a path forward that will meet the needs of both communities.
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.
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?
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.
But is there a problem when Trinity adds code, should
I care? Well the code is
wrong (review based on patch2.patch on mailing list). In an attempt to copy
everything from window maker code got added to KWin (particular readClass)
which already existed. Lack of knowledge about the KWin source code are
probably the reason that it is unknown that
KWin::Client::resourceName()/resourceClass() provide the window class
attribute.
Again, this is a great opportunity for getting it done right the first time.
If code implementation can be consistent from the beginning, it just helps in
the end.
Another problem is that the code is crashy. For me as
an experienced KWin
developer I only need to look at the code and see immediately were it is
likely that the code will crash. Consider that start is NULL and the following
line of code: start->readClass().
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.
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.
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.
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.
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?
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.
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.
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.
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...
The following is for those that know to comment on.
Based on that fact we have to look for a solution. In
my opinion the best
would be to just use our KWin. And we have some quite useful things about that
in our current development version:
* no longer depends on anything else from kde-workspace
* build options to disable "KDE 4" features (see
http://techbase.kde.org/Projects/KWin/Build_Options)
* mostly runtime dependencies to libplasma
* desktop integration possible through custom QML additions like e.g. Alt+Tab
* currently integrates with three desktop shells
* (under review) build option to change the name of the binary, which would
allow you to generate a kwin_tde or twin binary (automatic adjustment of all
configuration files, etc.) (see
https://git.reviewboard.kde.org/r/104299/)
* after feature freeze: branch to build kwin standalone without the need to
run cmake in kde-workspace.
As you can see this is a rather impress list of features which would allow TDE
to use KWin instead of their fork.
Of course KWin depends on Qt 4 and kdelibs 4. We have no interest to support
anything below Qt 4.7 and are currently preparing the transition to Qt 5 and
KDE Frameworks 5. I think that this is only a minor issue to Trinity as to my
understanding TDE can also use Qt 4.
We are open to discuss any concerns regarding integration a Qt4/kdelibs4 based
application into TDE. I am very sure that most of your possible concerns are
rather non-issues and that they can all be easily resolved.
I hope that you consider dropping your hostile fork of KWin and start to
collaborate with your upstream pears at KDE more closely.
Thanks for your time
Martin Gräßlin
KWin maintainer
--
David C. Rankin, J.D.,P.E.