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 > modularize? 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.
Regards Martin
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ compiz mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/compiz
