on Thu May 08 2008, "Kristian Lyngstøl"
<kristian-teylmYeCXyggsBAKwltoeQ-AT-public.gmane.org> wrote:
> 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.
You're right; I verified that fact last night. I hacked together
something that tries to reconstruct the entire environment from
/proc/${compiz_parent_pid}/environ when re-launching the parent process
(fusion-icon in my case) and when it worked, it worked. ;-)
The problem is that it didn't work whenever any environment variable had
spaces in it and my bash-fu is way too weak to know how to work around
that problem, even after hours of searching. Does anyone know how to do
it, or should I just rewrite my script in python?
> 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).
Hmm,
compiz.real --replace --sm-disable --ignore-desktop-hints ccp
--indirect-rendering
Do you suppose it might be the "ccp" that makes a difference? Perhaps
my strategy of killing and re-invoking the parent of compiz.real is
misguided and I should really just be re-invoking compiz.real.
/me goes off to experiment...
--
Dave Abrahams
Boost Consulting
http://boost-consulting.com
_______________________________________________
Dev mailing list
[email protected]
http://lists.compiz-fusion.org/mailman/listinfo/dev
