Re: [compiz] Move KDE Plasma Integration to KDE Git Infrastructure
Hi, 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. So you want to do a release whenever something significant in Kwin _or_ in Compiz changes? And do two releases (0.8, 0.9), at least as long as 0.8 is widely used? Fine with me then, as long as I don't have to go through hoops to commit ;-) 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. Yes, but as breaking changes can be made on both sides, it doesn't matter really which product KWD is part of. 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 ;-) I was talking about the classic, but composited tabbox. Not sure whether that one counts as effect. Regards, Danny ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] Move KDE Plasma Integration to KDE Git Infrastructure
On Thursday 20 January 2011 21:00:23 you wrote: > 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. That would be the first solution: own repository in KDE. But it still has some problems which would need to be solved. E.g. to push a commit to KDE's git repo, the committer must have an account. But we have awesome sysadmins to help on that if we agree on going such a way. > > 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. Which rules out the option to have it in workspace as AFAIK KDE's git infrastructure does not support submodules. But it would be something to revalidate with sysadmins. > > > 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. Well for Compiz I see there a better integration into Plasma, the "official blessing" from a competitive project and of course the chance for improving the existing integration (there are several things I would like to see improved, e.g. swap KWin's configuration modules against Compiz's when Compiz is used) and more collaboration (in that regard the refactoring work might become handy). > > - 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...) thanks, I just picked the first one in my inbox - both are too low traffic to know which one is the real ;-) Martin signature.asc Description: This is a digitally signed message part. ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] Move KDE Plasma Integration to KDE Git Infrastructure
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...) ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] Move KDE Plasma Integration to KDE Git Infrastructure
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 compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
Re: [compiz] Move KDE Plasma Integration to KDE Git Infrastructure
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 ___ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
