331854 - PreferencePanes disappeared

Status: RESOLVED FIXED

(Camino Graveyard :: Preferences, defect)

Description

[philippe (part-time)]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a1) Gecko/20060327 Camino/1.2+
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a1) Gecko/20060327 Camino/1.2+

With the 20060327 build, PreferencePanes (e.g. CamiTools, ExtraFonts.prefPane no longer appear in the preference window.

Reproducible: Always

Comment 1

[philippe (part-time)]

Forgot to add 20060326 build was fine.
10.4.5

Comment 2

[Joel Craig]

Same thing happened here with the March 26 experimental universal build.

Comment 3

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Looks suspiciously like bug 323780 could have done this, based on checkin and build times for the branch/trunk, and the fact that prefPanes are stored in the profile.

Comment 4

[Håkan Waara]

Seeing this too.

Comment 5

[Håkan Waara]

Attachment: Fix user profile prefpanes

The code was assuming extension prefpanes in the user profile folder was using the App support-folder.

While testing, I noticed that CamiTools seems to cache the profile path, or otherwise assume it. Just FYI.

Also tested with ExtraFonts, both in the "global" app support-folder, and a custom profile, and it works fine.

Comment 6

[Mark Mentovai]

Comment on attachment 216454 [details] [diff] [review]
Fix user profile prefpanes

Warning: comment nits follow.  OK to fix on checkin.

>Index: src/preferences/MVPreferencesController.mm
>     mLoadedPanes  = [[NSMutableDictionary dictionary] retain];
>     mPaneInfo     = [[NSMutableDictionary dictionary] retain];
> 

Before you do anything, you should introduce what's going to happen, or your 1-2-3 list doesn't have any context.  How 'bout:

      // Load preference panes from three different locations:
>+    // 1. First check inside the app bundle for the built-in prefpanes

Comma after the word "first".

>     NSString* paneBundlesPath = [NSString stringWithFormat:@"%@/Contents/PreferencePanes", [[NSBundle mainBundle] bundlePath]];
>     [self loadPreferencePanesAtPath:paneBundlesPath];

paneBundlesPath sounds stupid, could you please change it to panesInBundlePath on checkin?

> 
>+    // gets this Camino's PreferencePanes folder.

Move the "2." comment from below up here, and get rid of this comment.

>+    NSString* profilePanesPath = [[[PreferenceManager sharedInstance] profilePath] 
>+                                    stringByAppendingPathComponent:@"PreferencePanes"];
> 

Get rid of the newline between setting profilePanesPath and loading the prefpanes at that path.  And, for consistency, let's name this variable panesInProfilePath.

>+    // 2. Check inside this Camino's profile folder's PrefencePanes/ folder for extension prefpanes.

Replace "this Camino's" with "the active".

>+    [self loadPreferencePanesAtPath:[profilePanesPath stringByStandardizingPath]];
>+
>+    // 3. Check inside the global /Library/Application Support/Camino/PreferencePanes for prefpanes.
>     NSString* globalLibPath = [MVPreferencesController applicationSupportPathForDomain:kLocalDomain];
>     if (globalLibPath)
>     {
>-      globalLibPath = [globalLibPath stringByAppendingPathComponent:prefPanesSubpath];
>+      globalLibPath = [globalLibPath stringByAppendingPathComponent:@"Camino/PreferencePanes"];
>       [self loadPreferencePanesAtPath:[globalLibPath stringByStandardizingPath]];

It's not really the globalLibPath any more, is it?  Either introduce a new appropriately-named variable, or consolidate it:

        [self loadPreferencePanesAtPath:[[globalLibPath stringByAppendingPathComponent:@"Camino/PreferencePanes"] stringByStandardizingPath]];

>     }
>-    
>+

Thank you!

Comment 7

[Håkan Waara]

Fixed and fixed.
Thanks Mento for your 24/7 reviewing services!