> It could start as a simple listing of all the the things one CAN > specify. I've tried to "look around" but there seems to be no place > which hosts a list of all the possible "user.js" settings and what > they mean. Qualcomm DOES provide a list like that in addition to > having a mechanism for actually setting those "hidden" prefs. As I > said, I'd be happy with the list and I'll add them manually myself.
Yeah, the closest we have currently is a list of stuff inside the Camino package. The comments are decent--as always, at least there are SOME comments--but nothing explains what each setting does, and explanations are necessary when the preferences' names are stuff like "browser.download.save_converter_index". Big WTF there, from an end-user standpoint. (Sorry if it seems like I rail on this stuff, but having done retail service and support, little stuff like this sticks out to me.) And, no offense to the Camino devs at all, but this is ridiculous to see and insulting to users interested in, you know, actually using the program: Camino�s Hidden Features Ha, you thought I was going to make it easy for you! (From <http://www.mozilla.org/projects/camino/docs/profileprefs.html>.) Imagine if you saw that in Mac Help somewhere. > > An easy mechanism (other than directly adding them to "user.js") > would then be a feature request. But if we HAD such a comprehensive > listing, we still be way ahead of the game. > > BUT, there IS one big downside to the way Eudora does this. There is > NO mechanism to retrieve any form of comprehensive list of exactly > what all those settings are. This CAN become and issue if you are > troubleshooting and need to "delete prefs." That may very well fix > any application specific troubles, but now one is left with having to > re-figure out all your x-settings. > > For Camino, using an ASCII file is spot on and deals with the "need > to toss the prefs" issue. > If you're storing your preferences in a text file, and you have an about:config or whatever that has a bunch of little checkboxes with preference value names sans explanation, troubleshooting isn't any harder at all. Step 1: Remove preference file from profile directory. If things don't change, look elsewhere; it's not a preference file problem. If things go back to normal, go to step 2. Step 2: Do one of the following: A. Trash the preference file if you don't care about narrowing down a problem that might be a setting somewhere (if not a corrupted file); B. Perform "split-half" tests until you find the exact preference causing thr problem, assuming the prefs file itself isn't damaged. Split-halving is efficient and accurate, and doesn't rely on anyone knowing what "browser_setting_obscurethingy" does. But that's me, and I'm a tech for a living. End users, well, they don't always think about this stuff. Most Mac users, though, know to check if a preference file is screwing with something by moving it or deleting it. So in the end, I agree and disagree, I guess. What's definitely agreed on, and seems to be a popular sentiment in this thread, is that the preference values should at least be documented on some level for the user base. If we can't have standard settings and then 'touch if you dare' advanced settings in a preferences UI, then a nice list of what's what in user.js is needed. Safari and Camino are both very slick browsers, but if one wanted to answer a "why use Camino instead" question with something, one could reply, "Because there aren't many settings in Safari, but there are plenty of things you can set in Camino. Here's all the stuff you can do." Fun fun. -/- Mikey-San [this signature has been classified] _______________________________________________ Camino mailing list [EMAIL PROTECTED] http://mozdev.org/mailman/listinfo/camino
