Closed
Bug 7436
Opened 25 years ago
Closed 25 years ago
[BLOCK] ProfMgr needs prefs->Startup() and prefs->ReadUserPrefs() to be separated.
Categories
(Core :: Preferences: Backend, defect, P1)
Core
Preferences: Backend
Tracking
()
VERIFIED
FIXED
M7
People
(Reporter: racham, Assigned: mcmullen)
References
Details
(Whiteboard: I have this in my tree, but with many related changes to check in.)
In order to start communicator by switching a profile from Profile Manager, profile services require a method that allows all hashed prefs to be forgotten. Erasing all the hashed prefs until that would allow prefs/profiles to point at the newly selected profile. Profiles should be able to call ForgetUserPrefs when it switches the profiles and hence is the requirement for this method in nsIPrefs. Opened this bug as a reminder for the implementation of that interface.
Comment 1•25 years ago
|
||
Would this new routine also be responsible for all the pref-changed callbacks?
Steve, when this routine is called, all userprefs will be restored to their default values. Registered callbacks should occcur, I think. Or perhaps we can provide a boolean parameter for this. The prefs file should not be written out, however, when this call occurs.
Comment 4•25 years ago
|
||
After discussing this with John, here's the new plan: 1. prefs startup will no longer load any user prefs 2. application is now responsible for indicating user prefs to load by calling a new interface in prefs 3. prefs code to be slightly re-arranged to ensure all entry points validate structures, to make startup only load default prefs, to create new entry point 4. apprunner to be changed to call new entry point after profile is known 5. viewer to be changed to call new entry point with CWD to preserve current behavior This allows us to do the minimal computation for the correct result and satisfies all requirements (I hope.)
One thing about your summary that does not agree with my recollection (or opinion): the new interface should NOT specify any directory. The new interface should simply be ReadUserPrefs() (no parameters). To the extent possible, callers of the prefs interface should not be required to make decisions about where the prefs file is. That's the prefs manager's business. So viewer should not be passing in CWD, and the main() of apprunner will not be trying to compute the correct prefs file. That logic is all in prefs, and should remain there.
Comment 6•25 years ago
|
||
Hmmm. How was viewer going to inform you to use CWD while apprunner would use the actual profile information? Perhaps passing in a symbolic argument rather than the directory's nsFileSpec? (e.g. USE_PROFMGR=true/false) If so, this could be a parameter to the startup routine. Let me know how you thought this should actually work.
There was no difference in viewer before, and there need be none now. There is no need to pass in any parameters before, and there is none now. The decision to use the CWD is (and will remain) based on an internal decision of the prefs manager. This happens only if the file locator service is not available (which happens to be the case in viewer and perhaps some other embedding apps). If the file locator service is available, it can tell the prefs manager which file to open. This decision and the information supporting it are not the business of clients of libpref. They weren't before, and they should not become so now. Why is this controversial? We discussed factoring the code internally. From callers' points of view, Startup() is being replaced by two successive calls to Startup() and ReadUserPrefs(). Neither call needs any parameters. I don't want any re-engineering of the API apart from that.
Comment 8•25 years ago
|
||
It's not controversial, I'm just being slow in understanding how the file locator works because I don't know how it's connected to profile manager's presence. Given your last comments, then I modify my previous statements 4 & 5 as simply "viewer and apprunner call ReadUserPrefs() in the right place and everything else just works." Sorry for the obtusion.
Assignee | ||
Comment 10•25 years ago
|
||
By the way, I may still have time to do this!
Comment 11•25 years ago
|
||
John says that this is blocking the profile folks.
Summary: ProfMgr needs implementation of ForgetUserPrefs() method → [BLOCK] ProfMgr needs implementation of ForgetUserPrefs() method
Summary: [BLOCK] ProfMgr needs implementation of ForgetUserPrefs() method → [BLOCK] ProfMgr needs prefs->Startup() and prefs->ReadUserPrefs() to be separated.
Whiteboard: I have this in my tree, but with many related changes to check in.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 12•25 years ago
|
||
This is now checked in.
Comment 13•25 years ago
|
||
Is there a way to verify this thru running the profile manager yet? Or just mark this verified as some code that needed to be written to allow some more code to be written...
Assignee | ||
Comment 14•25 years ago
|
||
Well, to test this, you should be able to: 1. Create your first profile and set some distinctive preferences. 2. Launch again with the command-line option set to -ProfileWizard. When the profile wizard appears, create a second profile. 3. Verify that the preference you set in the first profile is not showing up in the second profile. Set another different distinctive preference, and quit. 4. Relaunch, and notice that the profile picker appears. You can launch with either profile now. 5. The preferences specific to one profile should never show up in the second profile.
Updated•25 years ago
|
Status: RESOLVED → VERIFIED
Comment 15•25 years ago
|
||
Thanks, John. I verified, with the 6/19 builds, that you can create and run two distinct profiles and that their preferences are kept separate.
Comment 16•25 years ago
|
||
Moving all libPref component bugs to new Preferences: Backend component. libPref component will be deleted.
Component: libPref → Preferences: Backend
You need to log in
before you can comment on or make changes to this bug.
Description
•