Description of problem: Normally the desktop-effects setting dialog can be used to switch between metacity (no effects) and compiz (3d effects) by replacing compiz with metacity and vice versa. The problem is that if metacity has compositing enabled (using the compisiting_manager setting in gconf), then compiz fails to start when metacity is still running, and desktop-effects fails reverts back to metacity after compiz stops. Version-Release number of selected component (if applicable): 0.8.4-2.fc12.x86_64 How reproducible: Always Steps to Reproduce: 1. With metacity running, run gconf-editor and enable compositing_manager under /apps/metacity/general 2. Run desktop-effects 3. Choose compiz Actual results: desktop-effects tries to run compiz, compiz breaks and desktop-effects runs metacity again and shows an error message Expected results: Compiz should start running. Additional info: When running compiz manually through the terminal, the following error message is shown: compiz (core) - Error: Could not acquire compositing manager selection on screen 0 display ":0.0" compiz (core) - Fatal: No manageable screens found on display :0.0 I can see a few possible solutions for this problem: 1.desktop-effects should disable compositing in metacity before replacing it with compiz. The problem with that is presumably you'd need to know that it should be renabled if metacity is ever to be run again, so desktop-effects need to check the status of compositing in metacity, disable it, run compiz, and then set compositing back on after either compiz runs successfuly or breaks. 2. desktop-effects should kill the currently running window manager before attempting to run compiz, on the change that the current window manager has a compositing manager that will prevent compiz from starting. 3. Make sure compiz can take over compositing from a running compositing manager.
Upstream bug is: https://bugzilla.redhat.com/show_bug.cgi?id=537791 Since we don't support the metacity compositor, I'm a bit disinclined to carry a patch, but a tested reasonable looking patch does exist.
The URL that you specified for the upstream bug is the URL for this bug...
This bug appears to have been reported against 'rawhide' during the Fedora 12 development cycle. Changing version to '12'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Sorry: https://bugzilla.gnome.org/show_bug.cgi?id=530702
Thanks for locating the upstream bug report - I think this should definitely be fixed in GNOME so I'll try to get this fixed there.
metacity-2.28.0-12.fc12 has been submitted as an update for Fedora 12. http://admin.fedoraproject.org/updates/metacity-2.28.0-12.fc12
metacity-2.28.0-12.fc12 has been pushed to the Fedora 12 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update metacity'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F12/FEDORA-2009-13084
metacity-2.28.0-13.fc12 has been pushed to the Fedora 12 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update metacity'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F12/FEDORA-2009-13084
metacity-2.28.0-13.fc12 has been pushed to the Fedora 12 stable repository. If problems still persist, please make note of it in this bug report.