Need platform specific prefs



19 years ago
14 years ago


(Reporter: colin, Assigned: colin)


({arch, qawanted})

arch, qawanted

Firefox Tracking Flags

(Not tracked)



(3 attachments)



19 years ago
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.

    xterm -e telnet %h %p
    create/terminal/detach "telnet %h %p"
    xterm -e tn3270 %h
    create/terminal/detach "telnet /term=IBM-3278-5 %h %p"
    xterm -e rlogin %h
    create/terminal/detach "rlogin %h"
    xterm -e rlogin %h -l %u
    create/terminal/detach "rlogin %h -l %u"


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
Would anything in vmspref.js then supercede any pref that came from initpref.js
or unix.js? Is that the way it works?


19 years ago

Comment 1

19 years ago
Neeti, can you tell me the right way to do this. Thanks, Colin.

Comment 2

18 years ago
Neeti, can you tell me the right way to do this. Or can you point me at someone 
who can? Thanks.

Comment 3

18 years ago
Can you help Colin with this?

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...
Keywords: qawanted

Comment 5

18 years ago
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.

Comment 6

18 years ago
cc'ing alec, dveditz

Comment 7

18 years ago
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"

but if vms.js overrides most of unix.js, just add "vms.js" to specialFiles[] and
copy prefs from unix.js into vms.js

Comment 11

18 years ago
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

Comment 12

18 years ago
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):


But the pref that "won" was the one in _openvms.js.  How come??

Comment 13

18 years ago
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?

Comment 14

18 years ago
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...

Comment 15

18 years ago
see also pref needs splitting and prefs need joining.  this trio is fun.
Bug 66877 - prefs files need to be consolidated
Bug 62755 - prefs files need to be partitioned / factored
Blocks: 66877
Depends on: 62755
Keywords: arch

Comment 16

18 years ago
sorry loops are bad
No longer blocks: 66877
No longer depends on: 62755

Comment 17

18 years ago
> 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?

Comment 18

18 years ago
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.

Comment 19

18 years ago
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.

Comment 20

18 years ago
no, don't do that because we are likely switching formats to a non-JavaScript
based format at some point

Comment 21

18 years ago
About to attach my fix for this. Looking for some reviews. Thanks.

Comment 22

18 years ago
Created attachment 24758 [details] [diff] [review]
Patch for OpenVMS specific prefs

Comment 23

18 years ago
Created attachment 24759 [details]
modules/libpref/src/unix/openvms.js (new file)
rmoa=dveditz if you need it

Comment 26

18 years ago
sr=alecf - I didn't mean to hold this up with the architectural discussion, sorry :)

Comment 27

18 years ago
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.

Comment 29

18 years ago
Checked in to trunk. Marking fixed.
Last Resolved: 18 years ago
Resolution: --- → FIXED
rs vrfy by checking lxr.
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.