[compiz] Move KDE Plasma Integration to KDE Git Infrastructure

Danny Baumann dannybaumann at web.de
Thu Jan 20 02:55:28 PST 2011


Hi,

> Let me first describe the current situation and the problems with it: Compiz
> and KDE releases are out of sync. We are currently more and more integrating
> features from the desktop shell into the window manager. In difference to
> other desktop shells (GNOME Shell, Unity) Plasma still allows to use a
> different window manager and has not removed any legacy code. This is a hughe
> advantage and although it does not look like other shells care about
> supporting different window managers I do not want to lose the possiblity to
> switch the window manager.

Agreed.

> Up to now Compiz has done a great job of supporting our additions, so that
> Compiz users get the same level of integration as KWin users. Nevertheless due
> to the fact that releases are out of sync Compiz users do not get new features
> when KDE has a release. This gets to a real problem when KWin changes the
> decoration API as that causes KDE4-Window-Decorator to crash (this is the most
> often reported bug against KWin). This has let to a stagnation in our
> decoration API as we don't dare to touch the code again. Nevertheless I plan
> to change the API in 4.7 and our most prominent decorations (Oxygen and
> Aurorae) will move to it.

Indeed, that's a problem.

> Now with the git transition there might be a solution for these kind of
> problems: Compiz's KDE Plasma integration is moved to KDE's infrastructure and
> could be released in sync with the rest of Plasma. This means you don't have
> to care about the release (done by KDE's release team). Additionally you get
> the advantages of the KDE community like the Krazy checks [1] and developers
> going through the code and fix common issues. Translation would be provided by
> KDE's translation infrastructure ensuring that the code is translated into all
> the languages KDE supports and providing a consistend translation.

I don't agree with this conclusion, though: Releasing KWD with KDE just 
moves the code-is-broken-due-to-unsynced-release problem from 'KWD is 
broken when KDE code is changed' to 'KWD is broken when Compiz code is 
changed'. I'm not sure how that improves things, especially given that 
Compiz 0.8 (which is still widely used) and Compiz 0.9 have different 
decoration APIs (to accomodate non-composited rendering and reparenting 
in 0.9).

> Concerning better support for changes in Plasma/KWin integration and
> decoration API, there is the chance that KWin developers will directly port
> changes to Compiz if it is in the same repository. Especially the decoration
> API is that small that we can add support to Compiz directly.

With the current state of things you could provide a patch and we could 
do our best to do a new release ;-)

> 3. Part of KWin. That is same as option 2, plus you could use KWin internal
> code. E.g. no need to duplicate decoration code any more, make use of KWin
> parts separated from core (e.g. Alt+Tab). This is probably the best
> integration you could get.

Taking aside the point that Alt+Tab is implemented in the plugins, not 
the decorator (which only renders the tabbox frame), I must say that 
personally the look of Kwin's Alt+Tab implementation is one of the 
things that makes me use compiz on KDE ;-)

> Personally I would prefer option 3 from an integration point of view. My
> current plans are to modulize KWin which would allow to make use of more KWin
> features.

What is your ultimate goal/plan here? What parts of Kwin do you want to 
modularize?

Regards,

Danny


More information about the compiz mailing list