[compiz] F8 desktop features

[Kristian Høgsberg]

David?

On 7/27/07, Kristian Høgsberg <krh at bitplanet.net> wrote:
> On 7/27/07, dragoran <drago01 at gmail.com> wrote:
> > On 7/27/07, Matthias Clasen <mclasen at redhat.com> 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?
>
> 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).
>
> Kristian
>