1.34 KB, patch
|Details | Diff | Splinter Review|
1.52 KB, text/plain
1.36 KB, patch
|Details | Diff | Splinter Review|
OpenVMS needs some changes to the default prefs. Here's the initial cut at those changes. For each pref, the first value is the existing UNIX value, and the second value is what it need to be for OpenVMS. unix.js print.print_command lpr print applications.telnet xterm -e telnet %h %p create/terminal/detach "telnet %h %p" applications.tn3270 xterm -e tn3270 %h create/terminal/detach "telnet /term=IBM-3278-5 %h %p" applications.rlogin xterm -e rlogin %h create/terminal/detach "rlogin %h" applications.rlogin_with_user xterm -e rlogin %h -l %u create/terminal/detach "rlogin %h -l %u" mail.use_movemail true false mail.use_builtin_movemail true false helpers.global_mime_types_file /usr/local/lib/netscape/mime.types /sys$library/netscape/mime.types helpers.global_mailcap_file /usr/local/lib/netscape/mailcap /sys$library/netscape/mailcap all.js security.enable_java true false My question at this point is, what's the right way to make platform specific changes to the prefs? Should I create a vmspref.js and then add that to http://lxr.mozilla.org/seamonkey/source/modules/libpref/src/nsPref.cpp#1572 Would anything in vmspref.js then supercede any pref that came from initpref.js or unix.js? Is that the way it works?
Neeti, can you tell me the right way to do this. Thanks, Colin.
Neeti, can you tell me the right way to do this. Or can you point me at someone who can? Thanks.
Seth, Can you help Colin with this? Thanks, Neeti
i can prolly verify the info in the resulting file[s] when this is fixed, but since i don't have access to a vms box, am adding qawanted to see if someone can really test this...
I am really looking for HOW to make platform specific pref changes. If someone can tell me, I'm willing to make the changes, test, and check in. Please don't check in the changes above. That was just my first guesstimate back in October and IS NOT TESTED AT ALL.
cc'ing alec, dveditz
the proper way to do this is to call yours vms.js, (not vmspref.js, that's just redundant) and add it to your packaging for your platform. prefs are loaded in alphabetical order (yes, I know thats a hack) so your vms.js would get loaded at the end, and override any default prefs. We may eventually have some better special ordering but for now that is what I would recommend
alec, I thought we parsed the specialFiles prefs in order?
actually they're loaded in *reverse* alphabetical order, because of the all-ns.js hack.
I think if colin adds "vms.js" to specialFiles (like we do for os2prefs.js and unix.js), it will "do the right thing". if you want your vms.js to override unix.js, you'll need to do this: Index: nsPref.cpp =================================================================== RCS file: /cvsroot/mozilla/modules/libpref/src/nsPref.cpp,v retrieving revision 3.135 diff -u -r3.135 nsPref.cpp --- nsPref.cpp 2001/02/07 07:55:58 3.135 +++ nsPref.cpp 2001/02/07 20:17:15 @@ -1742,6 +1742,9 @@ , "unix.js" #elif defined(XP_OS2) , "os2pref.js" +#elif defined(XP_VMS) + , "unix.js" + , "vms.js" #endif }; but if vms.js overrides most of unix.js, just add "vms.js" to specialFiles and copy prefs from unix.js into vms.js
it really sucks that we have to hand-edit prefs.js just to add a platform. we need a better solution my thought is this: just call it "platform.js" - it would exist in a different directory for each platform, i.e. unix/platform.js, windows/platform.js, and so forth. then we hardcode platform.js into nsPref.cpp
Something I don't understand. I created zzz.js, a.js, and _openvms.js, each containing the same pref but with different values. The same pref is also in the unix.js file. Turned on some file open tracing and here's the order in which the prefs files were opened (and I assume read): /dka0/work/m08opt/defaults/pref/initpref.js /dka0/work/m08opt/defaults/pref/zzz.js /dka0/work/m08opt/defaults/pref/xpinstall.js /dka0/work/m08opt/defaults/pref/security-prefs.js /dka0/work/m08opt/defaults/pref/mailnews.js /dka0/work/m08opt/defaults/pref/editor.js /dka0/work/m08opt/defaults/pref/config.js /dka0/work/m08opt/defaults/pref/all.js /dka0/work/m08opt/defaults/pref/a.js /dka0/work/m08opt/defaults/pref/_openvms.js /dka0/work/m08opt/defaults/pref/unix.js /dka0/users/cblake/_mozilla/default/prefs.js But the pref that "won" was the one in _openvms.js. How come??
It seems that whatever is found in unix.js or any prefs file from the bin area gets copied into the prefs.js file in the user's profile directory. If this is the case, shouldn't the pref files in the bin area only ever be read once, during some kind of "initialisation" phase?
if every pref is getting copied over, then that is a bug. the only prefs that are supposed to be written to prefs.js are the ones where someone calls SetXXXPref() on it...
> if every pref is getting copied over, then that is a bug. I just made one up and it got copied to user-profile/prefs.js Damn. This must be an OpenVMS-specific bug. I enter a report for it. Any idea where I should look for what could be causing this?
The prefs getting copied into prefs.js was my fault. I was using user_pref instead of pref in my .js files to set them. Grrr. Now its working as expected; initpref.js first, then all the others EXCEPT the special files in reverse alphabetical order, and finally the special files as listed in nsPref.cpp.
If I only have a few prefs that I want to set for OpenVMS and the rest are all the same as in unix.js, would it make more sense to have a small "if (vms)" section in unix.js. Would this be a better way to allow the different flavors of UNIX to each tailor the prefs, rather than each one having to have their own prefs file? This is assuming that you could do the "if (vms)" test in unix.js.
About to attach my fix for this. Looking for some reviews. Thanks.
rmoa=dveditz if you need it
sr=alecf - I didn't mean to hold this up with the architectural discussion, sorry :)
Created attachment 25067 [details] [diff] [review] revised patch (moved the include line down to its "normal" place)
since alecf sr the first patch, and the second patch looks fine to me, sr=sspitzer on the second patch. check that bad boy in.
Checked in to trunk. Marking fixed.
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → FIXED
rs vrfy by checking lxr.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.