bug-gnuzilla
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GNU IceCat 2.0.0.10-g1 and use with the alternate profile option


From: Giuseppe Scrivano
Subject: Re: GNU IceCat 2.0.0.10-g1 and use with the alternate profile option
Date: Mon, 03 Dec 2007 15:03:40 +0100
User-agent: Thunderbird 2.0.0.9 (Windows/20071031)

Hello,

I will try your changes to ./browser/app/nsBrowserApp.cpp as soon as I
can.  I am quite sure that I can apply the patch I found on
bugzilla.mozilla.org as it is without any additional modification.

Thanks,
Giuseppe


address@hidden wrote:
> On 12/1/07, Giuseppe Scrivano <address@hidden> wrote:
>> I modified the patch offered on bugzilla.mozilla.org to match our
>> needs, it creates and uses the ~/.gnuzilla/icecat directory to store
>> profiles data.
>>
>> It is not completely clean gAppData->name should be "icecat" and not
>> "firefox" without hardly-code the value we want, but at moment it is
>> acceptable to fix this problem.
>>
>> Giuseppe
>>
>> --- ./toolkit/xre/nsXREDirProvider.cpp 2007-05-08 21:25:29.000000000 +0200
> <snip>
> 
> After further tests,  ./toolkit/xre/nsXREDirProvider.cpp fix appears
> to introduce a new problem.  When using this method, in conjunction
> with the zhack-b script variation mentioned in my last post, if icecat
> is installed alongside firefox,  it creates a conflict when both try
> to run simultaneously.  If icecat is running and firefox is opened, it
> just opens a new 2nd instance of icecat rather than firefox.  If
> firefox is running and icecat is opened, it opens a 2nd instance of
> firefox rather than icecat.
> 
> This problem was also mentioned in the discussion at
> http://forums.mozillazine.org/viewtopic.php?t=532182
> 
> So it looks like the ./browser/app/nsBrowserApp.cpp does need editing to
> reflect the  --with-user-appdir=.gnuzilla option but even when used in
> combination with the nsXREDirProvider.cpp patch, the resulting icecat still
> ends up with "run-mozilla.sh" entries and requires a manual edit after
> compiling to replace each instance of "run-mozilla.sh with
> the "run-icecat.sh".
> 
> These are the ./browser/app/nsBrowserApp.cpp used in combination with the
> --with-user-appdir=.gnuzilla .mozconfig option.
> 
> --- ./browser/app/nsBrowserApp.cpp   2007-12-03 03:40:37.000000000 -0700
> +++ ./browser/app/nsBrowserApp.cpp   2007-12-03 03:33:22.000000000 -0700
> @@ -46,8 +46,8 @@
>  static const nsXREAppData kAppData = {
>    sizeof(nsXREAppData),
>    nsnull,
> -  "Mozilla",
> -  "Firefox",
> +  "gnuzilla",
> +  "icecat",
>    NS_STRINGIFY(APP_VERSION),
>    NS_STRINGIFY(BUILD_ID),
>    "{ec8030f7-c20a-464f-9b0e-13a3a9e97384}",
> 
> and this was applied to the icecat script after compiling to remove references
> to run-mozilla.sh (run from within the unpacked tarball created after
> compiling).
> 
> sed -i 's/run-mozilla.sh/run-icecat.sh/g'
> 
> The changes above result in  ~/.gnuzilla/icecat as the default profile
> folder location.
> Getting the resulting icecat script generated after compiling to use
> run-icecat.sh instead of run-mozilla.sh eludes me.  However, with this
> roundabout approach, icecat does create it's own profile folder
> location and it removes the conflict if firefox is already running.
> 
> I haven't done a test where the mozconfig option is set to one
> name like --with-user-appdir=.gnuzilla and the nsBrowserApp.cpp specifies
> another location but based on my previous testing, my guess is the
> nsBrowserApp.cpp setting might take precedence.  I also didn't test
> for what happens when the "icecat" specified in the
> ./toolkit/xre/nsXREDirProvider.cpp fix is different that what might be
> specified in ./browser/app/nsBrowserApp.cpp.
> 
> 
> --
> http://gnuzilla.gnu.org





reply via email to

[Prev in Thread] Current Thread [Next in Thread]