On Friday 20 April 2012 14:10:09 David C. Rankin wrote:
-----BEGIN PGP SIGNED MESSAGE----- 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.
Cheers Martin