On Mon, 2007-07-30 at 13:46 -0400, Kristian Høgsberg wrote: > David? > > On 7/27/07, Kristian Høgsberg <[EMAIL PROTECTED]> wrote: > > On 7/27/07, dragoran <[EMAIL PROTECTED]> wrote: > > > On 7/27/07, Matthias Clasen <[EMAIL PROTECTED]> wrote: > > > > Given that test1 is around the corner, I thought it might be a good idea > > > > to give a little status update on the features that the desktop team has > > > > been working on for F8: > > > > > > what happend to compiz-fusion? > > > > I've been punting this issue for a while; sorry about that, I should > > have been more involed in the debate there. I have two concerns about > > the proposed updates: > > > > 1) I'd rather not ship a git snap shot for fedora 8. If we know that > > there's a stable release on the horizon, that is, coming out withing > > the next 1 or 2 months, we can do an update, but if there's no > > expectation that a stable release is coming out in time for fedora 8, > > I'd rather wait. The concern here is mainly that we're starting to > > ship externally packaged plugins for compiz and we need an upstream > > maintenence branch (0.6) that maintains a stable plugin API. I don't > > know what the compiz schedule is for the current development branch > > but it still sees plugin API breaking changes at this time. As far as > > I know, there's hasn't been a stable release since the merge, but if > > most of the API changes to allow beryl plugins to run have been > > merged, maybe it would be a good idea to wind down and release 0.6?
I'd like get the 0.5.2 release out within the next couple of days. We could try to get a stable release out soon after that if 0.5.2 isn't too broken and people are interested in this. I got a lot of ABI/API breaking changes planned that I'd like focus on so someone else will probably have to be in charge of this stable release if we want it to happen anytime soon. > > > > 2) I don't know what the current status is on config plugins. I know > > there is interest in getting ccp configured as the default backend, > > but I don't know what the benefits of that is over gconf. I > > understand that gconf is GNOME specific, but I was thinking that the > > better approach was to move gconf and gtk-window-decorator to a new > > compiz-gnome subpackage. What is the compiz upstream position? My > > position is that we need to use the native configuration system of > the > > desktop environment (that is, gconf when running under GNOME) and > > reinventing new config file formats is almost never the right > approach > > (no matter how fun it is). compiz-gnome/kde sub-packages are recommended and we've used that in SLED/OpenSuSE for quite some time. There's no official upstream position afaik. My position is that people should be allowed to use whatever configuration backend they prefer and compiz upstream shouldn't favor any of them. My idea was always that we would have toolkit specific code from the storage system up to the gui to make it integrate and fill the need of each specific desktop environment perfectly. ccs has taken a different approach and is afaik an abstraction layer on top of the configuration system provided by compiz core. It has its own backend interface that allows different storage systems to be used. It provides an API for which applications like ccsm can written without direct access to a specific storage backend. I think that only a gtk-based settings manager is available today but it's fairly complete. There's probably hundreds of people on this list who knows more about ccs than me and I'm sure they'll jump in if you have any questions. -David _______________________________________________ compiz mailing list compiz@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/compiz
