[compiz] Move KDE Plasma Integration to KDE Git Infrastructure
kde at martin-graesslin.com
Thu Jan 20 10:42:53 PST 2011
On Thursday 20 January 2011 11:55:28 Danny Baumann wrote:
> 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).
The question is whether Compiz can provide BC. KWin provides BC for the
decoration API, but the problem is that KWD is not a decoration, but "plays
KWin" ;-) From a release point of view it seems easier to just also release
the KDE integration when Compiz does a release. From what we have seen KDE has
more releases with significant changes to API than Compiz has.
> > 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 ;-)
True but it is a difference whether it's part of our product or your product.
> > 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 ;-)
I forgot to mention that I was talking about the "classic" tabbox and not one
of our effects. Our classic Tabbox is more like a framework to create tabboxes
> > 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
I want to split up Workspace into small pieces which make it easier to
maintain and to test. Ultimate goal is to have Workspace in a state that we
can easily add Wayland support and drop X support ;-) Or so to say turn KWin
into a libwindowmanager.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 316 bytes
Desc: This is a digitally signed message part.
More information about the compiz