compiz - Jan 2011 - Move KDE Plasma Integration to KDE Git Infrastructure

Hi Compiz developers,

as you might know KDE will transition to git somewhen next week. This gives 
some new possibilities for the Compiz community, too.

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.

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.

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.

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.

Nevertheless there are a few things you should be aware of:
* Everybody with commit rights to KDE would be allowed to commit to it.
* You would need a KDE commit account to be able to commit to the repository 
(though KDE hands out commit rights rather easily and you are all proven 
members of the community)
* You would probably need to go through a two weeks Review Process which 
requires that there are no reported Krazy issues. Last time I looked into the 
Compiz KDE integration part the code was not in a state to get through review 
directly (As you are also using C++ I can only recommend to run KRazy checks 
on your main repository, too. It should also find generic options and KDE 
specific checks can be disabled.). Depending on where the repo will me moved 
that step might be omitted.

The last point gets me directly to where to move the code. There are several 
options:
1. Own repository either in extragear or as part of KDE SC. KDE SC would mean 
releases synced with rest of KDE.
2. Part of workspace repo. Same as option 1 with SC, but you get also access 
to the private libs of workspace. This means you could add support for KDE's
activities, use Kephal for screen handling and could in general add more 
integration for Plasma. Disadvantage: KDE does not use submodules so the code 
needs to be imported, which means the code really has to move to KDE 
infrastructure.
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.

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.

If there is interest from your side for going such a step, I would contact 
KDE's sysadmins to evaluate a possible merge path.

Cheers
Martin Gr??lin
KWin Maintainer

P.S. We will probably have another Plasma developer sprint in Europe around 
April. It would be nice to have some Compiz developers around to discuss 
possible future integration and collaboration.

[1]: http://quality.kde.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 316 bytes
Desc: This is a digitally signed message part.
URL:
<http://lists.freedesktop.org/archives/compiz/attachments/20110116/0d28d5ea/attachment.pgp>

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

On Sun, Jan 16, 2011 at 05:07:46PM +0100, Martin Gr??lin
wrote:
> 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.
> 
> 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.
There's an obvious solution that hasn't been mentioned.

Git is distributed.

Keep it both with kde and compiz.org. Sync up whenever necessary. No issues
with commit privileges, benefits from the KDE-community, no political
issues, translation-benefits, support for all versions of Compiz, and so
forth.

The only issue that would remain is ensuring co-operation, but that's no
different from how it is now. With two repositories of difference
"interest", you also emphasis that the code is glue that affects two
worlds.
> The last point gets me directly to where to move the code. There are
several
> options:
> 1. Own repository either in extragear or as part of KDE SC. KDE SC would
mean
> releases synced with rest of KDE.
Regardless of the conclusion, it should remain as its own repository. We
moved the decorators out of the core repository for several reasons, and
moving it to a different repository voids that.
> 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.
Maintaining something you need to run a window manager (Compiz) in a
repository of a different window manager(KWin) doesn't really add up. I see
your logic from the KWin perspective, but not the Compiz-perspective.

- Kristian

PS: I'm CC'ing the compiz list that's not at xorg, as the xorg
list is not the preferred list. (Our fault...)

On Friday 21 January 2011 07:57:17 Danny Baumann wrote:
> So you want to do a release whenever something significant in Kwin _or_
> in Compiz changes?
yes
> And do two releases (0.8, 0.9), at least as long as
> 0.8 is widely used?
not sure if 0.8 is really required to be supported and even if the Sam's
idea
to have both in one sounds better. If distri's continue to ship 0.8 together
with recent versions of KDE, it would be better to tell them to drop KWD 
(quite pointless to include something what crashes in all
cases).
> Fine with me then, as long as I don't have to go
> through hoops to commit ;-)
With git that should not be a problem ;-)

Martin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 316 bytes
Desc: This is a digitally signed message part.
URL:
<http://lists.freedesktop.org/archives/compiz/attachments/20110123/2d71fc8a/attachment.pgp>