Bug 532229

What command are you using to start compiz?

I use the Preferences>Desktop Effects to start compiz, which is :
compiz --ignore-desktop-hints glib gconf gnomecompat

Well that is wrong, try


compiz --ignore-desktop-hints glib gconf gnomecompat ccp


I am going to re-assign this bugreport to the desktop-effects package

desktop-effects launches Compiz via the 'compiz-gtk' script, packaged with Compiz.

Offhand (I'm not an expert in this) I don't think that mixing two configuration systems by loading both the gconf and the ccp plugins is a good idea - my opinion is for F13 we probably should drop our attempt to integrate Compiz into GNOME preferences and not use the gconf plugin.

+1 on dropping the attempt to integrate compiz into GNOME preferences. Upstream compiz-fusion does not seem to care the gconf plugin neither the libcompizconfig-backend-gconf. 

I'm not quite sure about upstream compiz, but from what i know compiz-fusion & compiz is now totally merged and moving towards compiz++ and libcompizconfig is still preferred.

The bug is in compiz-gtk script, which is in compiz-gnome package. As leigh123linux said in comment 3, it should contain ccp parameter.

From the official troubleshooting page in compiz-fusion.org (http://wiki.compiz-fusion.org/Troubleshooting#Is_Compiz_Running.3F), it says : "The ccp plugin is required for Compiz to interact with settings made in ccsm"; so i don't know why the parameter is dropped from compiz-gtk.

(In reply to comment #7)
> The bug is in compiz-gtk script, which is in compiz-gnome package. As
> leigh123linux said in comment 3, it should contain ccp parameter.
> 
> From the official troubleshooting page in compiz-fusion.org
> (http://wiki.compiz-fusion.org/Troubleshooting#Is_Compiz_Running.3F), it says :
> "The ccp plugin is required for Compiz to interact with settings made in ccsm";
> so i don't know why the parameter is dropped from compiz-gtk.  

Rather than dropped it was never been in it. 

During the early days of compiz, compiz uses gconf/kconfig backend to store its settings - mainly for desktop integration purposes. 

Then the Beryl project forked out, and instead of sticking to gconf/kconfig, they created a different configuration backend which is libcompizconfig. Supposedly libcompizconfig is an abstraction which can update to flat file, gconf , and kconfig, but sadly it the flat file support continues, but the gconf/kconfig support ended up (quite) abandoned. After Beryl become Compiz-Fusion, they continue using libcompizconfig

Fedora stick to gconf because of upstream Compiz preferred it. 

But considering Compiz-Fusion is now merged with Compiz now, I think its about time for Fedora to switch to ccp (rather than gconf) by default. I doubt libcompizconfig will go away. Other major distros also uses ccp.

I still don't understand, is ccp (compiz config plugin ) another way to handle changes in compiz config ?

compiz without parameters = no configuration support
compiz with gconf = compiz check and uses configurations from gconf 
compiz with kconfig = compiz check and uses configurations from kconfig
compiz with ccp = compiz check and uses configurations from libcompizconfig (and libcompizconfig stores in flat file)

and ccsm talks to libcompizconfig

then if i did understand right, desktop-effects should start compiz with ccp parameter only and depend on libcompizconfig, but that needs a complete rewrite, since desktop-effects relies on gconf

from an end-user perspective, this is really disappointing, because the user expects ccsm to work as expected, without changing the compiz-gtk script

Its a minor fix, really ... right now its the matter of compiz maintainer agreeing to it or not.

I even rewrote desktop-effects to python for this purpose 

http://code.google.com/p/kagesenshi-private/wiki/PyDesktopEffects

I had this discussion back when compiz-fusion was new, but Krh doesn't agree to it. 

I hope Jrb is more open to this idea.

I like the python idea, which is easily maintainable ( who can object ? ).

Anyway, is there a way to trigger a vote for the default desktop-effects to use ?
Or owning a package means the dictatorship upon it ?

Current Fedora maintainers for the relevant packages:

 Compiz: Adel
 desktop-effects: Me

What compiz-gtk does is really up to Adel; my basic idea for desktop-effects for F13 is that we just remove the two buttons in desktop-effects. They are pretty much just two random options and don't really reflect the things that people need most to configure with Compiz.

For F12, I think we just have to leave ccsm as one of the (many) packages in Fedora that don't work out of the box until you read some docs and set things up. That's not ideal, but changing the config backend for Compiz would be a major and potentially disruptive to do for now.

(In reply to comment #15)
> I like the python idea, which is easily maintainable ( who can object ? ).

Well, I'd object because I trust the desktop-effects code to handle the tricky job of switching between window managers. It's really bad to leave the user without a window manager if things go wrong. And I don't want to revalidate some other version of the code.

(And the C code does various low-level X and GL things that I wouldn't know how to do in Python, and don't seem to currently be handled by Mohd's version in Python.)

> Anyway, is there a way to trigger a vote for the default desktop-effects to use
> ?
> Or owning a package means the dictatorship upon it ?  

Owning the package does mean dictatorship, yes. I think now is an excellent time to start discussions with Adel about:

 - What configuration backend Compiz should use for F13
 - What the default configuration should be for F13

I didn't mean to put the quality of the code in question ( coz I have read it and appreciated it really, and by the way see bug https://bugzilla.redhat.com/show_bug.cgi?id=532618 ), just that the user experience on Fedora should be improved if we want Fedora to be used more by ordinary people. Forcing the user to go and search in docs isn't always a good solution.

(In reply to comment #17)
> I didn't mean to put the quality of the code in question ( coz I have read it
> and appreciated it really, and by the way see bug
> https://bugzilla.redhat.com/show_bug.cgi?id=532618 )

Yeah, saw that, will try to take a look soon at what is going on there.

> just that the user
> experience on Fedora should be improved if we want Fedora to be used more by
> ordinary people. Forcing the user to go and search in docs isn't always a good
> solution.  

Certainly not. But we have to balance that with stability. By the time I started looking at desktop-effects in August with respect to GNOME Shell, it was already pretty late in the F12 cycle to be making major changes. Now is the right time to be looking at changes for F13.

[ A sidenote:

In addition to the timing of major changes, the other reason for planning to make this change for F13 rather than F12 is that we hope by F13 GNOME Shell will be at a point where it will provide a good option for someone who wants a composited experience closely aligned with the GNOME vision. So the work that was done years ago to try and make Compiz integrate into the GNOME configuration - and picking up keybindings, etc, will be more easily abandoned.

For F12, GNOME Shell is more of preview; it's an interesting way to look at where GNOME is going, but probably only very dedicated people will run it full-time. ]

Hi,

I pretty much agree with Owen here, we can (and should) change this for F-13 to use ccp by default and remove the "cube and wobbly" options from desktop-effects.

But it is far to late to do a change like this for F-12.

The gconf plugin is going away upstream in 0.9.x so we have to move at some point anyway. (We might even move to this branch for F-13 but that depends on upstream progress).

Hope that clears things up, and I hope that everyone agrees that doing changes like this _two weeks_ before a release is insane.

(In reply to comment #19)
> Hi,
> 
> I pretty much agree with Owen here, we can (and should) change this for F-13 to
> use ccp by default and remove the "cube and wobbly" options from
> desktop-effects.
> 
> But it is far to late to do a change like this for F-12.
> 
> The gconf plugin is going away upstream in 0.9.x so we have to move at some
> point anyway. (We might even move to this branch for F-13 but that depends on
> upstream progress).

great!. then this shall be something to poke on for F13 :) ( and/or F12 updates )

> 
> Hope that clears things up, and I hope that everyone agrees that doing changes
> like this _two weeks_ before a release is insane.  

agreed 

(another package that would be affected is gnome-wm, for starting up compiz on login)

https://bugzilla.redhat.com/show_bug.cgi?id=377041

(In reply to comment #20)
> (another package that would be affected is gnome-wm, for starting up compiz on
> login)
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=377041  

No, compiz-gtk decides how compiz is started, the gnome-wm way has been obsolete for a while now.

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

Switching incorrect assignees to the default one.

*** Bug 513116 has been marked as a duplicate of this bug. ***

*** Bug 546855 has been marked as a duplicate of this bug. ***

I don't understand why a minor fix is taking such a long time. Should I add this to the F12 Common Bugs ?

"I don't understand why a minor fix is taking such a long time."

Owen's already explained that it isn't minor in impact, and that it won't be 'fixed' for F12.

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

The easy workaround is just to edit the /usr/bin/compiz-gtk file and change the start command.  Replace "gconf" with "ccp" and either logout and login or restart compiz.  Of course you will need to do this again if the package gets upgraded at some point.

Ok, I will add this to F12 Common Bugs as soon as the infrastructure is up again

why not patch ccsm to use gconf backend by default ?

Added this bug to F12 Common Bugs :

https://fedoraproject.org/wiki/Common_F12_bugs#ccsm-compiz-no-changes

*** Bug 516558 has been marked as a duplicate of this bug. ***

Nominating for F13Target since this is listed on F12 Common Bugs.

compiz-0.8.4-6.fc13 has been submitted as an update for Fedora 13.
http://admin.fedoraproject.org/updates/compiz-0.8.4-6.fc13

compiz-0.8.4-6.fc13 has been pushed to the Fedora 13 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 compiz'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F13/FEDORA-2010-1003

compiz-0.8.4-6.fc13 has been pushed to the Fedora 13 stable repository.  If problems still persist, please make note of it in this bug report.

this bug is filed against F12, and cannot be fixed by an update for F13. either ship an F12 update or explain why you cannot / do not want to fix this in F12, and close as WONTFIX (or CANTFIX).

(In reply to comment #37)
> this bug is filed against F12, and cannot be fixed by an update for F13. either
> ship an F12 update or explain why you cannot / do not want to fix this in F12,
> and close as WONTFIX (or CANTFIX).    

Let me point you to your own comment: https://bugzilla.redhat.com/show_bug.cgi?id=532229#c27

ah, right. then, for clarity:

Owen: "For F12, I think we just have to leave ccsm as one of the (many) packages in Fedora that don't work out of the box until you read some docs and set things up. That's not ideal, but changing the config backend for Compiz would be a major and potentially disruptive to do for now."

*** Bug 565343 has been marked as a duplicate of this bug. ***

Well, it's clearly too late to fix for F13 and probably too late for F14, but can we at least fix it in rawhide?

Also, there are other issues that are fixed by changing to ccp:

(1) absurd looking code in compiz-gtk:

        if ( [ -e /usr/lib/compizconfig/backends/libgconf.so ] || [ -e /usr/lib64/compizconfig/backends/libgconf.so ] )
        then
                exec compiz --ignore-desktop-hints ccp $@
        else
                exec compiz --ignore-desktop-hints glib gconf gnomecompat $@
        fi

So we check if the gconf backend exists and, if not, we use it anyway?  Huh?  (AFAICT, nothing provides libgconf.sp.)

(2) In the current state of affairs (F13 *and* F14), the standard gconf settings don't really work either.  Go to Preferences / Keyboard Shortcuts, set the shortcut for a terminal to Mod4+T, then press Mod4+T.  It works.  Then log out and log in.  Whoops, the setting is gone.  Upstream (when I asked on IRC) said that gconf wasn't even supposed to work and they wanted nothing to do with it.  But if you change the startup line to:

exec compiz --ignore-desktop-hints ccp gnomecompat $@

then even the setting in keyboard shortcuts works.

(3) Go to Preferences / Keyboard Shortcuts.  Try to change key binding for switching desktops.  Alternatively, try to find a setting to change the number of desktops.  Get annoyed that you can't find the setting at all.

Please repoen and target at some upcoming version of Fedora where this bug can finally get fixed.  Especially since the fix is one line.

At this point, I would recommend opening a new bug against Rawhide, and leave it up to the maintainer to decide whether to backport fixes to older versions.

I've tried changing /usr/bin/compiz-gtk as some have suggested, and it horribly breaks my Fedora 14 desktop.  If CCSM is useless, what is the method for configuring compiz in Fedora 14?

see http://lists.fedoraproject.org/pipermail/users/2010-November/386572.html

(In reply to comment #44)
> see http://lists.fedoraproject.org/pipermail/users/2010-November/386572.html

Thanks, I'll give it a shot.

*** Bug 653029 has been marked as a duplicate of this bug. ***

so, my initial call for this bug with the 0.9 port for F15 was to go with owen and adel's initial plan, and just dump the gconf stuff (I shifted it all into subpackages and they're not installed unless you explicitly install them, and libcompizconfig uses its ini backend by default).

However, after Bastien's mail to the list, I decided to look whether a gconf setup can work, and it can...if I install compizconfig-backend-gconf and switch ccsm to use the gconf backend it seems to do the job right, ccsm sets the parameters in gconf and compiz uses them. Since libcompizconfig (ccm plugin for compiz) is an abstraction layer which reads settings from any backend, you always run compiz with the 'ccm' plugin enabled now, whether you're using gconf or ini configuration. There's no 'gconf' plugin now.

So, if I could find the right bit to twiddle to change ccsm's default backend to gconf, we could ship with gconf configuration by default in everything and have it work out of the box...the main advantage of this would be that the GNOME keybinding integration would work. The drawback is that it'd force gconf on all compiz users, even those using it in, say, KDE. I don't know what to do. =) Thoughts, anyone?



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

I think that in order to be DE neutral, one might use libcompizconfig directly instead of using gconf, flat file, or kconfig.

you have to do that anyway in 0.9; everything has to go through ccp (libcompizconfig). but the thing is that we have to pick a default backend for libcompizconfig.

sam's also just let me know of another option: we can set up various profiles for libcompizconfig and set it up so different ones are used in different desktops. that's another option.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

+1 for gconf :-)

This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

With Fedora 16 and the "Classic GNOME with Compiz" session, the ccsm works and affects compiz just fine.

yeah, I think I mostly fixed this in f16. don't remember exactly how. dunno if it still works in f17.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.