Closed Bug 21135 Opened 20 years ago Closed 19 years ago

libpref really needs to be cleaned up and made ownable

Categories

(Core :: Preferences: Backend, defect, P3)

defect

Tracking

()

VERIFIED FIXED
mozilla0.9.1

People

(Reporter: brendan, Assigned: bnesse)

References

()

Details

Get rid of prefapi.c, flatten and simplify, cull redundancy, clean up crappy
overindented control flow and capricious error checks and non-checks, reduce
hidden globals such as gGlobalConfigObject and gPrefConfigObject, etc.

Heck, evacuate the old modules/libpref and make prefs a new component under
xpfe, if that's where it belongs.  It doesn't seem top-level under mozilla/ to
me, but I could be missing something.

/be
Status: NEW → ASSIGNED
Target Milestone: M13
yeeeha! I've actually wanted to do this for a while.
First up: turning prefapi.c into prefapi.cpp so that we can use standard string
allocators. (this is done in my tree already)

The cleanup ought to take 2 days of work after the above change.
Blocks: 21425
Target Milestone: M13 → M15
Sounds like great stuff, but not a beta stopper
spam: added self to cc list as this might affect my realm.
Moving all libPref component bugs to new Preferences: Backend component.  
libPref component will be deleted.
Component: libPref → Preferences: Backend
Blocks: 13803
I have started some work on this.. I'm breaking nsIPref up into two interfaces:
nsIPrefService - the master manager of all global pref stuff - loading config
files, etc... contains stuff like startup(), readUserPrefsFile() etc...

nsIPrefBranch - represents a branch of the prefs hiearchy, such as "browser."
(and the there is a root pref branch at "") which can be cached by a particular
component that's using it.

Both of these will have proper interCaps APIs and CopyXXXPref will be renamed
getXXXPref()...

In the process, I have found a bunch (10+) methods of nsIPref that are never
used and really shouldn't be exposed through an API.

Blocks: 23248
Blocks: 24612
not a beta stopper
I've done some cleanup to the interface already. I have stuff in my tree I'm
hoping to land in about two weeks.
I posted details to netscape.public.mozilla.prefs
Target Milestone: M15 → M16
spam: moving qa contact on some bugs from paulmac to sairuh@netscape.com
QA Contact: paulmac → sairuh
moving non-critical bugs to M20
Target Milestone: M16 → M20
Target Milestone: M20 → mozilla0.9
moving a few 0.9 bugs out to 1.0 to lighten my 0.9 load.
Target Milestone: mozilla0.9 → mozilla1.0
Bulk assigning bugs covered by the rewrite of nsPrefs to myself.
Assignee: alecf → bnesse
Status: ASSIGNED → NEW
Bulk updating some fields and accepting
Status: NEW → ASSIGNED
Keywords: nsbeta1
Target Milestone: mozilla1.0 → mozilla0.9
Marking this as a duplicate of Bug 46863 because all of this work is being done 
under that bug number.

*** This bug has been marked as a duplicate of 46863 ***
Status: ASSIGNED → RESOLVED
Closed: 19 years ago
Resolution: --- → DUPLICATE
Depends on: 46863
alecf has requested that I not dupe all these bugs, but rather close them as 
fixed after the work in bug 46863 has landed. Changing again...
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Target Milestone: mozilla0.9 → mozilla0.9.1
This work was completed as part of the preferences API refactoring.
Status: REOPENED → RESOLVED
Closed: 19 years ago19 years ago
Resolution: --- → FIXED
okay, rubberstamp.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.