On Thu, May 8, 2008 at 2:56 AM, David Abrahams <[EMAIL PROTECTED]> wrote: > on Tue May 06 2008, Adam Nielsen > <a.nielsen-HxjuLhO6/OPR7s880joybQ-AT-public.gmane.org> wrote: > > >> When I try to do the kill/re-launch as > >> part of my resume script, compiz runs, but with different settings than > >> the usual that come from fusion-icon. (...)
> > What happens if, once you've done a suspend and reloaded Compiz > > with the alternate settings, you change them? Next time you resume, do > > you end up with the updated alternate settings? > > Yep. Sounds like two different setting plugins. > > If so then it looks like the first time Compiz runs (at boot) it's > > being told to look elsewhere for its config files, and this custom > > location isn't being specified when you reload it. > > Maybe, but I still don't understand how that could happen. > > The command initially used to start fusion-icon is invoked as a gnome > session startup program, as simply "fusion-icon." However, the resume script > looks in the process list to decide how to re-invoke it and does: > > sudo -b -H -u dave XAUTHORITY=/home/dave/.Xauthority DISPLAY=:0.0 > /usr/bin/python /usr/bin/fusion-icon > > It doesn't look like any custom locations are being specified, ever. I do not think this is a configuration FILE issue. I would look at actual config plugins, which is determined by the wrapper script of your choice. In this case, fusion-icon. Could you try this with compiz-manager instead of fusion-icon? I suspect that certain environmental variables are the issue here, typically those used to determine what desktop environment you are using. This could cause the startup script to assume you're running different setups (kde/gnome/somethingelse) and thus start compiz diffrently.The easiest way to check this is probably using ps to check exactly how they start compiz up (or compiz.real, that is). - Kristian _______________________________________________ Dev mailing list [email protected] http://lists.compiz-fusion.org/mailman/listinfo/dev
