[compiz] F8 desktop features

[Sam Spilsbury]

In my honest opinion. CompizConfig Settings Manager is more of an 'advanced'
tool that presents a lot of options that the users dont want to see.
However, it makes Compiz very flexible in what it can do and how it can be
configured. It is also a nice gui-ish replacment for gconf-editor, which can
be a pain to use.

The gnome-xgl-settings and gnome-xgl-switch are perfect for users just
starting out with Compiz. I think that this is the 'simple mode' that we
were after, or at least gandalfn's gnome-compiz-manager. I think that also,
wherever it is appropriate, gnome-xgl-switch should be included in every
compiz-by-default distro, as it makes Xgl a whole lot easier to set up.

So in the end, I think that Compiz Fusion should take up gnome-xgl-settings,
and Distributions like OpenSUSE and Fedora, if they do not ship Compiz
Fusion by default, make it easlily installable.

Sam

On 7/31/07, David Reveman <davidr at novell.com> wrote:
>
> On Mon, 2007-07-30 at 13:46 -0400, Kristian Høgsberg wrote:
> > 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?
>
> 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 at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/compiz
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freedesktop.org/archives/compiz/attachments/20070731/40d76d80/attachment.htm