Message: previous - next
Month: April 2012

Re: Re: [trinity-devel] Resolving the TWin/KWin Fork Issue

From: Martin Gräßlin <mgraesslin@...>
Date: Fri, 20 Apr 2012 21:40:58 +0200
On Friday 20 April 2012 14:10:09 David C. Rankin wrote:
> Hash: SHA1
> On 04/20/2012 01:00 PM, Martin Gr��lin wrote:
> > 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.
> Martin,
>   I do apologize for the kwin/kde grouping. I did not recognize where the
> boundary line was drawn between kwin and kde.
to explain it: KWin is a KDE application. That means it is developed by the 
KDE community. There is no such thing as "KDE" as a software product. KDE 
represents the KDE Community. The KDE Community produces a few products and 
there are three software bundles which are released together twice a year:
* KDE Platform
* KDE Applications
* KDE Plasma Workspaces

This is often for historical reasons referred to as "KDE". But it is 
incorrect. There is no such thing as a KDE prodcut. The only relationship 
between the products is that all these products use the KDE Platform and are 
released on the same day. All the KDE Applications can be used on many 
Plattforms: GNOME Shell, Unity, XFCE, OS X, Mircosoft Windows, MeeGo Harmattan 
and the KDE Plasma Workspaces.

The KDE Plasma Workspaces represent the desktop shell and what belongs to it, 
that is the Plasma Desktop, Systemsettings, KDM and KWin. It is kind of the 
descendent of what "KDE 3.5" used to be or what you mostly mean when talking 
about KDE 3.5. KWin is the window manager and compositor used in the KDE 
Plasma Workspaces. It integrates with the KDE Plasma Workspaces, but does not 
require them, most of the Plasma integration is at runtime, everything else 
can be disabled at compile time (though there are at the moment still one or 
two calls to libplasma, which are going to be dropped soon).

I hope this helps you understand a little bit better how the KDE Community 
works and why you should not consider "KDE" as one thing. This also explains 
hopefully why e.g. the transition in kdepim has nothing to do with the desktop 
and that there is no such thing as a global version. Different software has 
different release cycles, that they by incident have the same version number 
does not mean anything.
> As for the thrust of my
> original response -- I agree with you, if we can avoid duplication of
> effort and prevent creating inconsistencies in twin/kwin -- it makes sense.
> The only sticking point there would arise if there was functionality that
> twin needed that kwin did not. In that case, the only option would be to
> have separate patches to kwin to provided needed twin functionality (if
> that is maintainable) or continue with the fork.
As stated before KWin has not dropped or removed any code (with a few 
exceptions). Based on that there should not be anything in TWin which you need 
and which is not present in KWin. If there have been additions to TWin which 
are not present in KWin they need to be upstreamed. We accept code if it 
matches our goals and our quality standards.
>   I have a practical question. If twin and kwin were to merge, how would
> that impact the current GIT hosting of the code? Would the twin code be
> included in the TDE GIT tree as a submodule our would the TDE git tree just
> receive updates from kwin as needed?  Thoughts?
The best solution would be to not host the code at all in TDE git tree. If you 
use a plain kwin you could just use our release tar-balls and add the patches 
from my (to be created) branch to build kwin standalone. A submodule is 
probably not possible as kwin is part of a greater kde-workspace repository.