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
Attachments: