Open
Bug 17199
(advancedprefs)
Opened 25 years ago
Updated 5 years ago
Advanced Prefs - Edit *all* prefs using tree UI
Categories
(SeaMonkey :: Preferences, enhancement, P3)
SeaMonkey
Preferences
Tracking
(Not tracked)
NEW
People
(Reporter: BenB, Unassigned)
References
()
Details
(Keywords: helpwanted, Whiteboard: See comment 74 for description)
We have so many, often useful, prefs, that aren't (and can't?) in the Pref UI.
We could add an "Advanced Prefs" dialog, which is basically an editor for for
the prefs.js file (on a lower level than the current Pref UI), that can insert
any possible key/value pair, together with documentation.
The documentation could be in XML or a database and contains all possible keys
with description, value type, default value and category. The latter inserts it
into a hierarchy, so that "mail.do_glyph_substitution" appears as
"Mail/Display/Text Conversion/Glyph Substitution".
The dialog could have a structure like the current Pref UI dialog: The Hierarchy
is displayed on the left, right top the name as header and the description and
right bottom the widgets, depending on the value type, and action buttons ("OK",
"Cancel" and "Reset to default").
Reporter | ||
Updated•25 years ago
|
Status: NEW → ASSIGNED
Reporter | ||
Comment 1•25 years ago
|
||
The hierarchy could be replaced by tabs containing both the hierarchy and an
alphabetical list (of the names) of the options. This would simply references to
these prefs, e.g. in the "Knowledge Base".
Reporter | ||
Comment 2•25 years ago
|
||
As both the UI and the datasource are in XML, the plan is to realize that using
XSLT. The XUL for both the hierarchy and the "content" on the right are created
on-the-fly, the first on opening the dialog and the latter on a click on an
item in the hierarchy. That way, the implementation is just some XSL, XUL and a
bit JS.
The problem is, that the XSLT processor in Mozilla 1. seems to be unusable yet
(not XP) and 2. doesn't support parameters, which we need for the creation of
the right "content".
Updated•25 years ago
|
QA Contact: cpratt → sairuh
Comment 3•25 years ago
|
||
spam: in my testing realm, so reassigning qa contact to me, en masse.
Bulk move of all Pref UI component bugs to new Preferences component. Pref UI
component will be deleted.
Component: Pref UI → Preferences
Reporter | ||
Comment 5•25 years ago
|
||
Mass-LATER
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → LATER
Comment 6•24 years ago
|
||
with the the Future milestone, i'm not sure what to do with Resolved Later
bugs... reopen, and set the milestone to Future? that way it won't get ignored
(which often happens to bugs which are resolved or verified). also adding
helpwanted kw, if there are any [external or otherwise] takers out
there. :-)
Status: RESOLVED → REOPENED
Keywords: helpwanted
Resolution: LATER → ---
Target Milestone: --- → Future
Reporter | ||
Comment 7•24 years ago
|
||
I am not sure, this bug is still the right way to go. My current preference is
the Deep Prefs Hierarchy(TM), see discussion in .prefs.
This bug might be good for a "TweakUI"-like power-user package.
In short: better than hand-editing prefs.js, but 2 different prefs dialogs are
hardly good UI (opinion of Ben Bucksch at 2000-07-29 :) ).
Comment 8•24 years ago
|
||
Attempting a better summary than "advanced prefs".
Summary: Advanced Prefs → [RFE] Advanced users: Prefs Tree UI, edit all prefs w/ tree
Reporter | ||
Comment 9•24 years ago
|
||
Readding old name of this bug, thus keeping longer summary.
Summary: [RFE] Advanced users: Prefs Tree UI, edit all prefs w/ tree → Advanced Prefs - Edit *all* prefs using tree UI
Comment 10•24 years ago
|
||
*** Bug 64492 has been marked as a duplicate of this bug. ***
Reporter | ||
Comment 11•24 years ago
|
||
Changing personal priorities. Giving away most of my bugs :-( (reassigning to
default owner).
I will still track these bugs closely. If you need my input, feel free to ask me.
New owner: Please do *not* close these bugs (as WONTFIX or whatever you may
find) unless they are fixed. Rather, reassign to <nobody@mozilla.org>, if you
don't want to work on them.
Assignee: mozilla → matt
Status: REOPENED → NEW
Target Milestone: Future → ---
Comment 12•24 years ago
|
||
OT: I am very interested in seeing this bug implemented. It makes me wish i knew
how to program.
How about adding this to: prefs - advanced - miscellaneous?
Comment 13•24 years ago
|
||
This bug shou not be limited to just prefs.js settings; but to other settings as
well.
One setting I would really like to see implemented is to be able to turn off the
dreaded cascading of new windows. I place my window EXACTLY where I want it, and
want all new windows to appear there too.
Comment 14•24 years ago
|
||
Please also see (and CC and vote for) bug 68134 >>Need list of "tweakable
settings" in advanced preferences<< for some good comments/arguments why this
feature is important and how it can be implemented without confusing the "PC
challenged" user (i.e. prefs - advanced - miscellaneous, should be clear and
hidden enough to indicate to EVERYONE that these are non-required settings).
Comment 15•24 years ago
|
||
*** Bug 67996 has been marked as a duplicate of this bug. ***
Comment 16•24 years ago
|
||
Sorry, but that didn't insert my comment:
For Boris:
On the first place, thanks Boris. And if the implementation for bug 17199 is
done right, then it might be helpful. I will make this a dup of that other bug,
and i will add my concerns to that bug, which are backed up by a recent user
poll by then. I only hope to protect my kids in a way. Also that bug is rather
old by now. And belief me, this is all about marketing and pushing mozilla
forward with an competitive edge.
I'm not looking to make mozilla bloated, because that's out of the question.
Powerful, Flexible and Customizable that's more like it. I'm also not looking
for tweaks, but i do like to know more about pref. setting in general. But
that's a completely different story.
For Matthew:
Matt, my comment was short, but that's just because i run into a long ammonia.
For now my computer time is limited, and you know, we all have our bad days.
Just bear with me Ok?
Most friendly, HJ.
Comment 17•24 years ago
|
||
Oh lord, what a begin, sorry for that but this had to be inserted for bug 67799.
Comment 18•24 years ago
|
||
*** Bug 67996 has been marked as a duplicate of this bug. ***
Comment 19•24 years ago
|
||
> One setting I would really like to see implemented is to be
> able to turn off the dreaded cascading of new windows. I place
> my window EXACTLY where I want it, and want all new windows to
> appear there too.
I would imagine this would be a prefs.js setting if implemented.
Comment 20•24 years ago
|
||
*** Bug 68134 has been marked as a duplicate of this bug. ***
Comment 21•24 years ago
|
||
Bug 46029 deals with a GUI for choosing a different UA string as 'seen' by
webservers (e.g. turn us into IE5.5 according to the webserver). Ben B pointed
us at this which I think is a better choice. CC self.
What is the status of this? Are the technologies ready for use in Mozilla? If
so, is it just a matter of discussing possible designs and implementing the best?
Reporter | ||
Comment 22•24 years ago
|
||
> What is the status of this?
Untriaged. I bet, Netscape won't implement it. So, whoever is interested, take
it (but double-check with current owner, to be sure).
> Are the technologies ready for use in Mozilla?
As for XSLT, I don't know. Might be. But there are other ways to implement it,
without XSLT.
> If so, is it just a matter of discussing possible designs and implementing
> the best?
Yes.
Comment 23•24 years ago
|
||
See also bug 74887.
Gerv
Comment 24•24 years ago
|
||
Due to the high demand (see duplicates and their CC lists) the keywords:
*nsCatFood*, and *MostFreq* should definetely be added.
How about making the prefs appear in a seletion list. Below the selection list
would be the data/variable selection area that changes according to what pref is
selected.
+-Miscellaneous Prfs-----------+
| |
| Pref 1 |
| Pref 2 ---s-e-l-e-c-t-e-d--- |
| Pref 3 |
| Pref 4 |
| |
+------------------------------+
| Brief Description of Pref 2 |
| |
| <x> Yes |
| < > No |
+------------------------------+
Comment 25•24 years ago
|
||
maybe buttons for:
- "Reset *selected pref* back to Default value" and for
- "Reset *all Miscellaneous prefs* back to default values"
Shorter names for the buttons would be needed, of course.
Comment 26•24 years ago
|
||
or just have the default value in brackets behind each pref:
+- Miscellaneous Prefs -----------+
| /\ |
| Pref 1 |x||
| Pref 2 | ||
| Pref 3 ---s-e-l-e-c-t-e-d--- | ||
| Pref 4 |_||
| Pref 5 \/ |
+---------------------------------+ +-----------------------------+
| Brief Description of Pref 3 | | Brief Description of Pref 2 |
| | | |
| [ 12 ] (Default = 8) | or | <x> Yes |
| | | < > No (Default) |
| | | |
+---------------------------------+ +-----------------------------+
Comment 27•24 years ago
|
||
*** Bug 74887 has been marked as a duplicate of this bug. ***
Comment 28•24 years ago
|
||
Peter: what you propose is unworkable because it requires the UI to know more
about each pref than the pref system does.
We basically have the following information:
- pref name
- pref type (string, bool, int)
- current pref value (if any)
We also need the system to work with arbitrary numbers of preferences, and
automatically incorporate new ones as they are created. There are far too many
of them for a drop-down box. We either go with Ben's UI, and have a tree, or go
with mine, and have a text box.
My idea has the advantage of not requiring XSLT, and probably being simpler to
implement (get a PrefsService, query for the given prefname string, update if
it's found, suitable errors if not.) His has the advantage of being more
user-friendly.
On the other hand, given a) advanced users can cope with my UI (it's just a
shortcut for them) b) non-advanced users can probably cope with an email/web
page telling them "stick this value in here and that value in there and press OK
and it'll do what you want".
If we do mine, we can always do the other later. Unless anyone wants to step up
to the plate for doing the tree view now...
This bug is not mostfreq - it does not have 10 dupes. I very much doubt it's a
Netscape priority either, and certainly not nscatfood. :-(
Gerv
Comment 29•24 years ago
|
||
When prefs are created, they must exist (i.e. be documented) somewhere. All we
need to do is add certain mandatory datafields (database) to that documentation
(i.e. pref description in common terms, default value, pref type, current
value). Then the prefs ui could retrieve those values and display them in the
list i proposed.
This would deal with an arbitrary number of prefs and automatically incorporate
new ones as they are created since they would be retrieved from the datasource
on startup or on prefs UI loading.
Making users (especially novices) find some newsgroup and edit system files
(prefs.js) is definetely always a very bad idea - let's forget that "solution"
pronto.
Having the number of dupes be the criteria for a *mostfreq* bug seems silly to
me. It merely reflects the number of people who are too clueless to see if their
bug has already been reported. Wouldn't it be better to base *mostfreq* on the
number of persons in the CC list? I think so :)
Reporter | ||
Comment 30•24 years ago
|
||
> what you propose is unworkable because it requires the UI to know more
> about each pref than the pref system does.
I agree wtih Peter L. here: The intention was to build a (XML-based) database of
available prefs and their values. Allowing a user to set 6 as value, while the
pref is an enum and only 0-3 are defined, is not too useful. That is, when you
wan to provide a comfortable UI.
> We either go with Ben's UI, and have a tree, or go
> with mine, and have a text box.
Or both, one after the other. Please do not close this bug, after you
implemented your short-term proposal in bug 74887.
For the record: While I definitely prefer my inital suggestion of a tree with a
comfortable UI, I have no (strong) objection, should somebody decide to
implement Gerv's suggestion first.
Peter L., the mostfreq keyword is mainly to stop too many dup reports, i.e. to
help the bug triagers with their work. It is not so much a marker of the
importance of a bug. (But it is an indirect one, just as the cc list is.)
Comment 31•24 years ago
|
||
> Allowing a user to set 6 as value, while the
> pref is an enum and only 0-3 are defined, is not too useful.
But going down this route will lead to a world of pain where the prefs database
gets out of sync with reality, and it either lets you set invalid values or,
worse, won't let you set valid ones. We must be getting on for 100 prefs, with
more added every week.
As you will note, I've closed the other bug, not this one. I have no intention
of closing this one :-)
Gerv
Reporter | ||
Comment 32•24 years ago
|
||
Gerv, you are right. But the current situation is a problem, and we need a
authorative database of prefs anyway (apart from the default prefs). This bug
would "encourage" programmers to keep the database current, because they like
probably like the comfort of the UI as well, and have an interest themselves to
set the values via the UI -> keep the database current.
Comment 33•24 years ago
|
||
As a side note, I doubt anyone could make an authoritative list of prefs without
trawling the entire source base - AIUI, there's no central registry for them.
This is another hurdle to cross :-(
Gerv
Comment 34•24 years ago
|
||
If the "database" were dynamic (i.e. the prefs UI would retrieve /whatever/ is
in the database), then we could gather together prefs gradually, but implement
the UI now, with only the first set of available prefs.
Comment 35•24 years ago
|
||
Isn't that what all.js is for?
Reporter | ||
Comment 36•24 years ago
|
||
> If the "database" were dynamic (i.e. the prefs UI would retrieve /whatever/
> is in the database)
That is the plan, that's what I meant with "on-the-fly" in my Dec 1999 comment.
Note that we don't necessarily need XSLT for it, it canbe coded in JS, just that
XSLT would be the most elegant or coolest solution.
> Isn't that what all.js is for?
all.js (et al) only ontains the default prefs. It does not contain (in a
computer-readable form) all possible values or a description of them. Actually,
for many prefs, there is no description at all currently.
Also, it does not contain really all prefs (but almost all). For these missing
prefs, we fall back to a hardcoded default value ...or misbehave :). In any
case, missing entires in all.js (et al) are a bug.
So, yes, creating such an database (for the current Mozilla) is work, but it is
doable. And Peter is right, we don't need a complete database to implement or
even check in the UI.
Comment 38•24 years ago
|
||
mitch, this is the bug i was mentioning earlier... perhaps your webpage/script
suggestion would be an alternative to this? feel free to ping me on irc to
discuss...
Comment 39•24 years ago
|
||
Yes, we can do this with a webpage and some signed scripts (as soon as I get
those working again). With a signed script, a webpage can display and modify prefs.
Updated•24 years ago
|
Target Milestone: --- → Future
Comment 40•23 years ago
|
||
Problem:
You want to keep a DB of prefs with all possible values for each pref.
Idea:
When the browser loads the prefs, if the prefs value is not in the DB then the
setting is not valid. This would create a checks and balance system between
programmers adding prefs and them also adding the possible values of that pref
to the DB.
Of course, this would be a startup speed issue, but I think the prefs are being
compiled and cached for speed currently, so the speed issue would only be a
factor the next time you started the browser.
Not valid settings follow the current logic flow when a pref has an invalid value.
Comment 42•23 years ago
|
||
In addition to the current value of a pref, we also know the default value (if
the pref is set in all.js et al. If this were for super-advanced folks we can
leave it up to them to know what they're touching. We'll display the uneditable
default value so they can get back to something sane if they screw up.
This would be good for a QA audit, too: we could work down the list and find
prefs that are in-use (exist, have a value) but which don't have a defined
default value.
Comment 43•23 years ago
|
||
->samir.
am also wondering if bug 98569 would be considered a dup of this...? esp now
that about:config has been implemented. [yay!]
Assignee: vishy → sgehani
Comment 44•23 years ago
|
||
*** Bug 98569 has been marked as a duplicate of this bug. ***
Comment 45•23 years ago
|
||
what is with a regular expression to check the value.
this could be implemented as a value in the xml source. to save runtime i prefer to check the values only after a change in the advanced prefs dialog.
i think it is not a good idea to handle all.js for default values and a xml file as a database.
Comment 46•23 years ago
|
||
Couldn't we implement this as inline editing (ILE) of the about:config tree?
Summary: Advanced Prefs - Edit *all* prefs using tree UI → Advanced Prefs - Edit *all* prefs using tree UI (about:config?)
Reporter | ||
Comment 47•23 years ago
|
||
This bug was supposed to do much more than about:config does. It was planned
that the user gets inline documentation about the pref in question, the possible
input is restricted by the allowed options for the relevant prefs etc..
Making about:config editable might be a good workarond in the meantime, but I
don't know, if it's worth the effort - the full-blown solution shouldn't be
hard, now that Transformiix is supposed to work. That's what I wanted to use 2
years (!) ago.
Summary: Advanced Prefs - Edit *all* prefs using tree UI (about:config?) → Advanced Prefs - Edit *all* prefs using tree UI
Comment 48•23 years ago
|
||
*** Bug 103963 has been marked as a duplicate of this bug. ***
Comment 49•23 years ago
|
||
I don't know whether about:config is in outliner / tree or not, but if so,
couldn't we leave the config items displayed as they are, except adding an arrow
on the left of each? This, once "opened", would turn the fields editable and add
buttons like "OK", "Cancel", "Reset to default" below. Wish I could find a good
example screenshot at the moment.
Comment 50•23 years ago
|
||
It looks like another way to provide prefs editing is in bug 110090.
Comment 51•23 years ago
|
||
See also bug 14969, "[RFE] TweakUI-like Package to attract audiences that like
to customize".
Reporter | ||
Comment 52•22 years ago
|
||
*** Bug 147750 has been marked as a duplicate of this bug. ***
Comment 53•22 years ago
|
||
I filed an enhancment request about this yesterday (bug 147750), without knowing
that it was already there (sorry about that).
I just want to say that I'd vote for Peter Lairo's suggestion in adding a
description to the database (?) of mozilla preferences, so the UI could also
display what a specific setting does. Since adding a description for each
setting will take time, space could just be reserved for it, then we would add
more and more descriptions of the most common settings as time went by.
'Hixie' Hickson (comment #46) also mentioned the about:config method. This
actually lists exactly the features that we are talking about here. By just
making that list editable and add an extra column (pref description), we would
have the functionality already. Then we could just put that code into a section
of the Preferences window.
Comment 54•22 years ago
|
||
This would be very similar to the Gruop Policy Editor in Windows 2000/XP. There
you have the list of preferences, along with a description and default value.
Since we're talking about more or less advanced features, it's not so important
that it's *very* easy to use. It could, in my opinion, look very similar to the
current about:config list, with the addition of being editable. maybe you could
just double click on a true/false setting to toggle it? And string values would
display an edit-box when double-clicking (like when you rename a file in Explorer).
Reporter | ||
Comment 55•22 years ago
|
||
I noted that I have some examples for the XML doc on my website, and I don't
seem to have referenced them here. <http://www.bucksch.com/1/projects/mozilla/17199>
As for the implementation, it's now 2.5 years later and XSLT in Mozilla still
can't be used to generate XUL. Additionally, I have no idea if I can pass
parameters to the XSLT via the URL.
Maybe a hard-coded converter (implemented in JS) of the XML doc to XUL would be
the more realistic way. It would read the XML file(s) into a DOM, generate the
XUL tree for the categories out of it and when the user clicks on an item in the
tree, it looks up the data in the XML DOM and generates the editing UI out of it.
Reassign to nobody, to clarify that nobody is working on this.
Assignee: sgehani → nobody
Comment 56•22 years ago
|
||
I _might_ be willing to tackle this as "Baby's First Mozilla Project".
I am an amateur Borland "Delphi" programmer with no non-DOS
or non-Windows experience. With Delphi, I am more than capable
of writing an applet that can
1.) Display the contents of all.js, prefs.js, and user.js in
a browsable and searchable interface.
2.) Allow the user to make changes to the values.
3.) Write the changes back to either prefs.js or user.js.
As to what I can do with programming tools/languages I'm
not familiar with?
As well, it must be noted that all.js, prefs.js, and user.js
are NOT a comprehensive list. Example: if you don't already
know about browser.bookmarks.file you are not going to find
it in one of those three .js files.
Comment 57•22 years ago
|
||
Is this a duplicate of Bug 110090 ?
Reporter | ||
Comment 58•22 years ago
|
||
oh, duh! I just found out about XUL templates and that they might be even more
appropriate than XSLT. I feel a bit like an idiot. I'd like to try it out, but
unfortunately, I have no time right now.
Updated•22 years ago
|
Alias: advancedprefs
Comment 60•22 years ago
|
||
*** Bug 170661 has been marked as a duplicate of this bug. ***
Comment 61•22 years ago
|
||
*** Bug 173465 has been marked as a duplicate of this bug. ***
Comment 62•22 years ago
|
||
Here is a proposed solution that requires very little in the way of changes to
the current prefs system and shouldn't be too hard to implement:
Make each pref have its own URL (for example
about:config/browser/popups/showPopupBlocker). At this URL have a page that
allows the user to set the value of the pref according to its type (bool,
string, whatever). It doesn't have to have any extra documentation other than
the pref name, because most people won't go browsing the jillions of prefs.
Instead this makes it possible to make a *link* to a pref. Now when someone
hears about a whiz-bang new Moz feature, all they have to do is click the link
given in the Slashdot comment (or whatever) and they get a page that allows them
to set it right away. No mucking with text files.
I think this will solve the #1 problem this bug is trying to solve - people hear
about a cool new moz feature but don't like having to find text files and edit
them and restart mozilla and all that. No extra documentation (taking up
valuable memory space and download time) is needed since this is not meant to be
a way of discovering new prefs. This just lets people have easy access to any
pref they personally know about, and be easily told about any pref in Mozilla.
If you *really* can't live without the ability to browse the prefs with
documentation, that could fit in nicely with this solution too. Just make each
pref group a directory (about:config/browser) showing each pref and have
documentation on each individual pref page. But I think that the descriptions
aren't really necessary; the problem is mostly setting specific prefs that you
have heard about, not surfing the prefs to find new cool ones, and besides, the
pref names are quite descriptive already by themselves.
Comment 63•22 years ago
|
||
I have just posted an XPI to the mozdev site (http://preferential.mozdev.org)
that provides this very functionality.
Eventually, I plan to add documentation on each bug from an RDF datastore, but
for now, the XPI simply allows access to a preference tree that can have entries
added, edited and deleted on the fly. The current results are very similar to
that proposed by comment 62.
Comment 64•22 years ago
|
||
The Preferential Mozilla extension (http://preferential.mozdev.org) is now at
version 0.3.1. It has been successfully tested as providing a tree UI for all
Mozilla preferences on Windows 98 for both Mozilla 1.2b and Phoenix 0.4.
Any feedback on this tool would be welcome.
Comment 65•22 years ago
|
||
There's no way to load this pref viewer in the content area, or using URLs, is
there? That could be dangerous.
Comment 66•22 years ago
|
||
This is sorta covered by the new editable about:config screen now - no?
Reporter | ||
Comment 67•22 years ago
|
||
*sigh*, no, read up.
Updated•22 years ago
|
Comment 68•20 years ago
|
||
Is there any hope for this feature request? Perhaps the author of
Preferential should be asked if he'd be willing to create a fix for this bug.
Anyways, this bug has been inactive a rather long time...
Keywords: qawanted
QA Contact: nobody → mozillamonks
Comment 69•20 years ago
|
||
Sure, if preferential made it so that it could provide the same functionality
through about:config by overriding chrome://global/content/config.xul, I don't
see why not as long as preferential were allowed to be included as a default
extension. I have some complaints about preferential, though:
*Filter doesn't work (filter does in about:config)
*Needs a root tree element so you can truly Expand All
*Whereas preferential is tree-only (it seems) and about:config is list-only,
we'd want a combination of the two
If we went this route, preferential should probably supply a slightly different
UI for its about:config replacement than it does in a window since standard
menus shouldn't be inside a tab. I like the UI for about:config, and this could
be expanded upon. Perhaps clicking "Advanced Preferences" could simply always
load about:config in a tab.
Summary: Advanced Prefs - Edit *all* prefs using tree UI → Advanced Prefs - Edit *all* prefs using tree UI in about:config
Reporter | ||
Comment 70•20 years ago
|
||
Geez. Read up. This bug is *not* about <about:config>, but a specific GUI idea.
It's not "Preferential" either. Resetting summary.
Summary: Advanced Prefs - Edit *all* prefs using tree UI in about:config → Advanced Prefs - Edit *all* prefs using tree UI
Comment 71•20 years ago
|
||
Ben: The discussions in this bug are old and its hard to follow exactly what
people are talking about in the beginning because a lot has changed. Also, most
these comments were prior to the inclusion of about:config for editing prefs,
and the creation of Preferential.
Please recap what this bug is about because I think there is a lot of confusion
in the last year's worth of comments, and that is what people generally go by
because the older discussion is out of date and also there are conflicting
statements and it also appears incomplete. Whoever orignally CCed themselves has
probably forgot a lot of the original discussion that occurred within newsgroups
and IRC. Can you recap what the most popular ideas are and _exactly_ what this
bug is about?
Is this basically a discussion for a UI that shows the documentation for
preferences that are contained within the source code? I remember something to
that affect, and people mentioning that the documentation could be within
.properties files, etc. If so, why is tree UI mentioned in the summary. Is a
tree necessary to show documentation for the preferences?
It almost seems like 3 different things are discussed in this bug. Please clarify.
Updated•20 years ago
|
Product: Browser → Seamonkey
Comment 72•17 years ago
|
||
What is the status of this bug as of now? Is it dead? There were no activity since 2004!
Comment 73•14 years ago
|
||
Since there was no clarification, what this bug really is about and the functionality to edit all prefs is given by about:config, I'd suggest to mark it wontfix.
Whiteboard: [se-radar] → [se-radar] [CLOSEME INVA/WONT?]
Reporter | ||
Comment 74•14 years ago
|
||
Bruno, as said above, the idea was expanded on the newsgroup a bit, then drowned into a discussion with Matthew Thomas.
<http://groups.google.com/group/netscape.public.mozilla.prefs/browse_frm/thread/68dd94274bbcb58e/a76398d6c86a0d97>
The idea was:
> the prefs should be designed (semantically) well. But the real solution
> to the problem is to organize prefs well.
>
> In the long term, I'd like to organize them in a deep hierarchy, with
> the "frontpage" (the panel you get by clicking an a parent node) of a
> subtree not being a collection of misc prefs (which didn't well fit in a
> subpanel), but the most important ones. That way, a user with limited
> needs wouldn't have to care about the deep hierarchy. If a user misses a
> pref on the "frontpage", he can explore the hierarchy in more depth.
>
> (See also bug 17199.)
Robert O'Callahan wrote:
<http://groups.google.com/group/netscape.public.mozilla.prefs/msg/12e66c73ba72391a>
> the maximally usable set of preferences is different for different kinds
> of users. Most people can only handle a small set of preferences.
> On the other hand, I just love programs that give me scrolling lists
> with hundreds of checkboxes. So, I would like to have lots of preferences
> that are usually concealed.
about:config is a hack, not a solution.
1) There are absolutely no descriptions what the prefs mean.
The description is very much needed.
2) It's not discoverable, not browsable. Unless you remember the pref name,
it's very hard to find.
3) It only lists prefs that are in the default prefs file. The infamous
"browser.dom.window.dump.enabled" for example - I *always* have to look
it up, even now, because I can't remember it and it's not in the defaults,
because default prefs are claimed to slow things down. That's not usable
in my opinion, I am angry every time I have to set this pref.
This bug would fix all of them. It would have a database of prefs, including descriptions and allowed values, as described at the top and at the URL. They are also categorized, so you can browse. Each category page summaries the most important prefs for that category, so you naturally get a nice UI, where you don't have to drill down deep for commonly needed prefs, but you can drill down as deep as you need to.
This solves the problem that the amount of usable prefs UI, and the number of needed prefs, varies a lot between users and there's no clear cut-off point. The point is different for each user. Given that you can dive deeper, per brach, as much or little as you want, and it's always gentle, this solves the problem.
Whiteboard: [se-radar] [CLOSEME INVA/WONT?] → See comment 74 for description
Updated•5 years ago
|
Assignee: ben.bucksch → nobody
QA Contact: mozillamonks
Target Milestone: Future → ---
You need to log in
before you can comment on or make changes to this bug.
Description
•