Good idea, taking a vote on *which* of the myriad options are most important to the user base.
Perhaps even *mentioning* and linking to this vote on the main page for Camino. And then, those options that don't make it into one of the main, easy GUI panels, could be in an "Advanced" or "Esoteric" panel/tab, with several sub panels/tabs even -- i.e., hey novice user, don't say we didn't warn you -- and hey, advanced user, you want options, here they are. And anything so esoteric that it doesn't make it into the GUI, then yes -- definitely document it in a read me file, perhaps an .html document with clickable links to implement these options (not unlike Eudora where you can type in advanced settings, as "X-EudoraSetting666" or whatever, yes?), if that's possible. Perhaps, like someone said, an AppleScriptStudio applet, which could quit Camino, directly manipulate the relevant "filename.js" file, and re-launch Camino. I love Eudora, and I'm aware that they have many hidden options, plus a ton of exposed options. They manage to keep the exposed ones organized well, even though there's tons of them. And the hidden ones are documented on their website. We should be able to do it at least as well as they do. And yes, turning images off should be in the main, easily visible, options. WTF, indeed. I was actually quite surprised, first time I used Camino(Chimera) to find how *few* options there were, including that. Perhaps the developers could take a look at the prefs/options for IE, Safari, and OmniWeb (the main OS X competition, yes?) and if there's a pref/option that's in *all 3* -- make it plainly visible in the "easy" portion of Camino's options. And also make plainly visible, whatever options we vote for. And then put the other stuff in some "Advanced" or "Esoteric" grouping, or a sub-grouping within that. And the completely oddball stuff in a read me. > Hidden . . . I don't like that word when it comes to options. Perhaps there > doesn't need to be a UI control for EVERYTHING if simplicity is what you're > shooting for, but hidden is a stupid concept. What you'd want, if not UI > controls for placing entries in a text file (user.js, for example), is a > document that sits next to the readme that explains not only where to put > preference entries, but what each does. > > A file buried in > Camino/Contents/MacOS/anotherfolder/whichfolderwasitagain/oneofthesefiles.js > doesn't cut it. (Yeah, the app needs it, but if that's what an end user is > given to look at to figure out what prefs to set for what, don't be shocked > that people don't find reasons to move from OmniWeb or Safari.) > > Anyway: Hidden is bad; documented is good. If a developer isn't going to > include GUI controls for preferences people just might want to set or alter, > he'd damn well better document the alternative he's chosen to go with. > > [snip] > > If you had a GUI toggle for content filtering (on/off), you could assign a > keystroke to it and turn it off for that second it takes to load the > affected site. ;-) > > /tongue-in-cheek > > In all seriousness, what if the devs took a vote on either the Camino main > site or the dev list to see what preferences people wanted in the > preferences UI, and then just added X of those? You don't need ALL of the > Gecko settings (since there are so freakin' many that it WOULD clutter up > the preferences dialog), but that doesn't mean more Gecko and > Camino-specific options shouldn't be added. How come I have to edit a text > file to turn images off? WTF? > > -/- > Mikey-San > [this signature has been classified] -- Ed Mechem < mailto:[EMAIL PROTECTED] > _______________________________________________ Camino mailing list [EMAIL PROTECTED] http://mozdev.org/mailman/listinfo/camino
