Daniel <[email protected]> wrote: > Rob wrote: >> Daniel <[email protected]> wrote: >>> Rob wrote: >>>> Daniel <[email protected]> wrote: >>>>> Rob wrote: >>>>>> Daniel <[email protected]> wrote: >>>>>>> Not wanting to get picky-picky (because of the work you do for us SM >>>>>>> users) but reading between the lines here, does this imply that hidden >>>>>>> prefs don't (necessarily) do anything, or did you just mis-type "hidden" >>>>>>> rather than "absent"?? >>>>>> >>>>>> You have to understand that in about:config you can basically type any >>>>>> name you want and set it to any value you want. Only when the program >>>>>> code is reading the name you typed it will do anything. There is a >>>>>> pre-populated list of names and values that you see, but even that >>>>>> does not guarantee that changing them actually has any effect at all. >>>>>> There can be names/values in the list that are never (or no longer) >>>>>> used anywhere in the program. >>>>> >>>>> Rob, I am aware that "There is a pre-populated list of names and values >>>>> that you see". I am aware that more can be hand-added. I am also aware >>>>> that there is a pre-populated list of names and values that you *don't* >>>>> see i.e. hidden prefs. >>>> >>>> But that is not correct. There is no such list. >>>> Hidden prefs are those prefs that *are* read from the program code, >>>> but are *not* in the list of prefs that you see. When you know the >>>> name of such a pref, you can add it and set its value. Just you can >>>> add "this.is.a.pref" and set it to 1. The difference is that no piece >>>> of code checks the value of "this.is.a.pref" and so this setting has >>>> no effect. >>> >>> So, Rob, I typed there were prefs that we *don't* see, and you typed >>> there's no such list then you continued to typed that there are hidden >>> prefs as part of the program source code. >>> >>> So which is it?? >> >> They are in the sourcecode, but not in a list. They are scattered all >> over the source lines that together are seamonkey. >> Take the pref "advanced.mailftp" as an example. It is referenced in >> the sourcecode like this: >> >> rv = prefs->GetBoolPref("advanced.mailftp", &useRealEmail); >> >> This reads the advanced.mailftp pref and puts the value in useRealEmail. >> >> It is also in the normal list of preferences because in all.js it shows: >> >> pref("advanced.mailftp", false); >> >> I.e. there is a visible pref advanced.mailftp and its default is false. >> >> Now look at the pref "app.updatecheck.override". This is read in the >> source code: >> >> return !Services.prefs.getBoolPref("app.updatecheck.override"); >> >> However, it is not listed in all.js. And so you'll never know about >> it when you open about:config unless someone has manually added that >> pref and set a value. That is what is called a hidden pref. >> >> To make a list of those, you would have to scan all sourcefiles for >> calls to the functions that retrieve preferences, and get the parameters >> of those functions. This is not a trivial task, because the parameter >> may not be a literal (like in the examples above). The name can be >> dynamically constructed from literal parts and variable parts, in a >> program variable, which is then passed to the function. > > So I cannot set this app.updatecheck.override according to how I might > *prefer*, so I don't think we are talking about a pref, just some > element/value that the programmers required!!
A pref is just a parameter for the program. They all are element/values that the programmers required. Some of them are deemed to be useful for everyone, and those are in a list that you see in about:config. Others are mainly for debugging or to cover some unusual cases, and sometimes it is discouraged to use them (like the above "app.updatecheck.override"). Those are used by the program but not put in the generic list. You have to know about them by other means before you can use them. Sure it would be nice if there was a complete documentation system where everything that can be configured using prefs (or other configuration files, there are others in both the program and the profile directories!) can easily be looked up and searched. Many times I have needed to change some behaviour and I had to resort to Google which found some partial lists, some on mozilla.org websites, some on other sites, usually partly out-of-date. And also bugzilla items that mentioned them (also out-of-date and I have been told here that I cannot use bugzilla for documentation). Final responses usually only came from developers here or on the IRC channel. Of course I understand that it is a lot of work to setup such documentation, and more work to keep it uptodate as the program develops, and it is not achievable in many free software products to maintain it with the limited resources available. _______________________________________________ support-seamonkey mailing list [email protected] https://lists.mozilla.org/listinfo/support-seamonkey
