Rob wrote:
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.
O.K., I think I'm splitting hairs Rob, so I'll let it rest.
Tks for trying.
--
Daniel
User agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:25.0) Gecko/20100101
Firefox/25.0 SeaMonkey/2.22 Build identifier: 20131023190953
or
User agent: Mozilla/5.0 (X11; Linux x86_64; rv:25.0) Gecko/20100101
Firefox/25.0 SeaMonkey/2.22 Build identifier: 20131023190942
_______________________________________________
support-seamonkey mailing list
[email protected]
https://lists.mozilla.org/listinfo/support-seamonkey
