Created attachment 92688 [details] [review]
patch from the Ubuntu package

Not surprisingly, the patch doesn't apply against current trunk, so I can't really comment on the general situation, but a few things still leaped out of the code at a first fly-over:

* parts of the code seem to originate from control-center. Just pasting another copy back is not such a great idea

* hard-coded paths for metacity and compiz

* current_configured_wm leaks str

* has_composite: doesn't GTK provide API to query that?

Looks like this is going to have to wait until 2.22 as we're not in feature freeze too.

So, this is base on Soerens original code for the Desktop Effects capplet in F7, 
but the actual ui elements were made more meaningless. While we agree with the idea to move the Desktop Effects capplets into a tab of the Appearance capplet, 
we should probably discuss the contents of the tab a bit...

I'll attach screenshots of the original and Ubuntu dialogs for comparison purposes.

Created attachment 96338 [details]
desktop-effects-fedora.png

Created attachment 96341 [details]
desktop-effects-ubuntu.png

The Ubuntu screenshot is outdated, the current dialog is http://people.ubuntu.com/~mmueller/new-desktop-effects-capplet-6.2.png

I really like the last screenshot, from ubuntu. What does the 'Einstellungen' ('Customize' ?) button open? Could you post a screenshot of that also?

the button run the ccsm configuration tools if it's available

I don't like last screenshot. It doesn't really change anything compared to the first one; it only adds redundant icons and longer text. The text is highly subjective: "more aesthetically pleasing", and imo not appropriate. The whole idea of treating this like a one-dimensional choice from none to "full crack" is wrong.

I think the last is nice.

I agree with Matthias in comment 10, the options use very subjective text and do not explain what the effect of the option is.

Metacity now has a compositor that can be enabled via a gconf key. Should this also be controlled by a "Desktop Effects" option? The only reason I can imagine for turning this off is if the hardware or drivers are not good enough.

> Metacity now has a compositor that can be enabled via a gconf key. Should this
> also be controlled by a "Desktop Effects" option? 
>
yes, it should

Created attachment 108117 [details] [review]
First try at a more generic solution

Here's a first version of this with a more generic solution. What is missing is what to do for customizing metacity compositing stuff, and what to do to choose a window manager, that is, if running metacity without compositing, enabling desktop effects should enable metacity compositing or run compiz?

The ubuntu patch is using a deprecated gconf key, btw (/desktop/gnome/applications/window_manager/default), but contains the nice feature of allowing the user to go back to the previous configuration. Should that be in also?

Created attachment 108119 [details] [review]
Patch updated to include a few comments from Thomas Wood

This version hides the customize button when using metacity, and also packs the widgets to make it fit in a smaller place (ie should we move it to the Interface tab?).

Screenshot -> http://www.gnome.org/~rodrigo/Screenshot-Appearance-Preferences.png

> Metacity now has a compositor that can be enabled via a gconf key. Should this
> also be controlled by a "Desktop Effects" option? The only reason I can imagine
> for turning this off is if the hardware or drivers are not good enough.

Another reason could be serious bugs in the compositor...lets hope those get fixed till 2.24...

I appreciate the work going on to consolidate the various desktop-effects dialogs here.  Now if you'll excuse me for ranting a bit, here's a couple of comments to the latest revision of the patch:

 - The command line to launch compiz should be compile time configurable.  We don't use the configuration configration plugin crack in Fedora, and I'm not sure why you would want to do it for a GNOME applet (where you can assume GConf).  We launch compiz as 'compiz --replace glib gconf'.

 - If you're not running a binary driver, you'll need to set LIBGL_ALWAYS_INDIRECT before launcing compiz.

 - We don't ship ccsm (the settings manager launched by the 'Customize' button) by default and I don't think the wealth of options presented by ccsm is suitable for GNOME.  The desktop-effects in Fedora deliberately only presents a couple of options (cube on/off, wobbly on/off).

 - Having one full tab with just one checkbox and a button to launch another configuration dialog seems like bad design.  The customize button depends on an extenal application that may not be installed (it's not part of the core compiz package).  The desktop-effects dialog should be self-contained with a couple of meaningful options and not cause a cascade of dialogs.

We also have a timeout when selecting compiz that reverts to the previous setting unless the user acknowledges that the switch worked out.  I think that's a good safety valve to keep in there, since opengl+compiz support is still somewhat hit and miss (unfortunately).

I'll attach the source for the Fedora desktop-effects for reference.

thanks,
Kristian

Created attachment 108182 [details]
Fedora desktop-effects.c

Upstream repo is 

  git:///git.fedoraproject.org/git/desktop-effects.git

I had a quick look at the screenshot in comment 16.

Perhaps the "Desktop effects" tab could be merged with "Interface"? After all, it's just one checkbox and a button.

Also, "Window Manager" doesn't really mean much to non-geeks. I don't have any better suggestion off hand, but I'm sure there is one. :) (Same for "Desktop effects" but that won't be a problem if you merge it with the interface tab.)

(One more thing. Is this really the way forward with configuring stuff that happens to be implemented with the help of a compositing manager? What does the "Customize" window contain? I really think more thought should be given to what the user want to configure and integrate it at the proper place in the control center. This is a problem though since Metacity and Compiz have different effects etc. But GNOME should IMHO integrate well with one compositor and since Metacity is in GNOME... but I guess it depends on the future plans for the compositor in Metacity. I.e. will there be more effects? (Didn't Havoc mention something about a Clutter based compositor in Metacity on his blog... ))

With "effects" above I don't necessarily mean eye candy but also things like "exposé" etc.

(In reply to comment #18)
>  - Having one full tab with just one checkbox and a button to launch another
> configuration dialog seems like bad design.  The customize button depends on an
> extenal application that may not be installed (it's not part of the core compiz
> package).  The desktop-effects dialog should be self-contained with a couple of
> meaningful options and not cause a cascade of dialogs.

I meant to say "The desktop effects tab should be self-contained".

A different approach: put in this new tab controls for a commons subset of "effects".

Note: currently the Metacity compositor can be only ON or OFF; let me assume that we can choose what "effects" we like to run in metacity, we could provide a layout like:

  <b>General</>
    [x] Enable animations and special effects

  <b>Windows Effects</b>
    [x] Add a shadow
    [x] Show previews in Alt-Tab selector
    [x] Use animations on moving/minimizing/maximizing
    [x] Exposé like selection        <-- better label
    ( More Options... )

Note that when you enable the compositor manager, you automatically enable stuff like the animation for panel launcher, the transparency for nautilus icon when performing a d'n'd, all dock-like applications and so on.
Those stuff can't be tweaked in metacity or compiz and are always available when you turn on the composite manager, so I think could be good split controls in <b>General</b> and <b>Win Eff</b> groups and add a note in the first group explaining that actual "effects" could be available depending on running apps.

(In reply to comment #23)
>   <b>General</>
>     [x] Enable animations and special effects

Why would you not want this ("animation for panel launcher, the transparency for nautilus icon when performing a d'n'd"...) enabled? The only valid reason for most would be performance but that should be one big desktop wide "limited resources"/"enable special effects" or whatever switch.
 
>   <b>Windows Effects</b>
>     [x] Add a shadow
>     [x] Show previews in Alt-Tab selector
>     [x] Use animations on moving/minimizing/maximizing
>     [x] Exposé like selection        <-- better label

Same here. Though shadow is more of a look and feel thing. One crack idea is to put it in the metacity theme. And to "disable" Exposé, just don't use the short cut or set the short cut to "disabled" in keyboard preferences. Or just don't select Exposé in the "non existent hot corner preference thingy".

Anyway, I realize these are just some examples you threw together but I don't think lumping together everything that happens to be implemented by means of a compositor in the CC UI.

... is a good idea.

This patch doesn't handle actually changing what wm gets started at login, does it?

The plan in gnome-session 2.24 is for gnome-wm to go away, and for the session to just include metacity, with some new cleverness in the .desktop files and the session capplet to allow people to cleanly select alternate window managers, described here: http://live.gnome.org/SessionManagement/RequiredComponents. (That may not end up being 100% accurate. And gnome-wm can't actually go away completely anyway, because that would break people's saved sessions...)

Probably gnome-session should have a dbus method that the control center can call to update the user's startup items so that either compiz or metacity is started as appropriate. (Or alternately, gnome-wm could move from gnome-session to gnome-control-center, and use a gconf key to decide whether to start compiz or metacity.)

If you enable animations, then you can add dependent group below that option:

<b>Animations</b>

[x] Window open: [Zoom V]
[x] Window close: [Fade V]
[x] Minimize: [Magic Lamp V]
[x] Slide: [Slide V]
[x] Focus: [Dodge V]
[x] Use wobbly effect for maximize

Maybe as Martin stated it would be much better and user-friendly (and easier?) to move all options about enabling composition and customizing effects to the theme. Just like we had a "high performance, less style" theme for GTK, we could have themes using compositor and others that stay with basic metacity. There's just a need to extend the theme format: it should be able to specify standardized effects (common to metacity and compiz) or wm-specific effects (that are disabled if you're using the another wm).

The question that remains then is how to choose to use compiz over metacity or the contrary?

(In reply to comment #28)
> Maybe as Martin stated it would be much better and user-friendly (and easier?)
> to move all options about enabling composition and customizing effects to the
> theme.

FWIW, that's not what I'm suggesting.

IMHO limiting the options to some preconfigured default sets or even ship compositor settings as part of the theme is a bad idea.

Different WMs have been around for years and some people have preferred to uses them over metacity in gnome. Yet, there was never a setting for this exposed in the menus. So this does not have to change IMHO. The default WM (and defaut settings for the WM) should be set by the distribution. For configuring Compiz further, there are various nice tools like CCSM. Something like this should also exist for Metacity, for those users who don't want to use the default.

(In reply to comment #30)
> For configuring Compiz further, there are various nice tools like CCSM.
> Something like this should also exist for Metacity, for those users who
> don't want to use the default.

Well, much of what's in CCSM would be better of properly integrated in the desktop though.

Should the "effect" Tab only support Metacity only? Since Metacity is the default for GNOME?

There won't be a desktop effects preference for GNOME 3, the fallback will be automatic.

And how are people supposed to force the fallback mode if some users request it? Or if they deployment policy is to stick to the panel? You know that often users don't like things changing too much; and sometimes the automatic fallback won't detect a piece of hardware, and you'll have to do it by hand (yes, it always works that way).

(In reply to comment #34)
> And how are people supposed to force the fallback mode if some users request
> it? Or if they deployment policy is to stick to the panel? You know that often
> users don't like things changing too much; and sometimes the automatic fallback
> won't detect a piece of hardware, and you'll have to do it by hand (yes, it
> always works that way).

You'll need to ask Owen Taylor about that, he was tracking this particular piece of work. It's also been discussed in d-d-l recently.

You are not supposed to force fallback mode from the UI. If fallback fails, chances are very low you can get to a settings panel to manually force fallback anyway.

As for deployment policies, editing the files in /usr/share/gnome-session/sessions/ works fine.

That's not the scenario I was considering. I was wondering about conservative users that would prefer to continue using the panel while still willing to upgrade to benefit from improvements in other domains (apps, new distribution...). Should they make this choice through GDM before logging in?