Open Bug 38521 (prefbar) Opened 24 years ago Updated 16 years ago

Preferences Toolbar, for most commonly used prefs

Categories

(SeaMonkey :: UI Design, enhancement)

Product:
SeaMonkey
Component:
UI Design
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

People

(Reporter: mpt, Unassigned)

References

(
URL
)

Details

(Keywords: helpwanted)

Attachments

(1 file)

Custom toolbar, at bottom.
9.65 KB, image/gif
Details 
I think that Navigator and Messenger (at least) should have a Preferences 
Toolbar, to allow quick editing of the most common preferences for that 
component. The toolbar would be off by default.

This would end the whinging of 4.x users that certain prefs which were accessible 
with a simple menu click in 3.x now require them to ferret deep into the prefs 
dialog.

Straw-man proposal for contents of the Preferences Toolbar in Navigator and 
Messenger:

Navigator
---------
[Style :^] [Size :^] [*] Custom fonts [*] Custom colors [*] Images [*] JavaScript

Messenger
---------
when an HTML message is being shown:
[Style :^] [Size :^] [*] Custom fonts [*] Custom colors [*] Attachments in-line

when a plain-text message is being shown:
[Style :^] [Size :^] [Wrap mode   :^] [*] Color quotes  [*] Attachments in-line
This would be a pretty cool feature, especially for those times when you want to 
quickly toggle a pref in a matter of minutes (e.g. "this damn site is using JS 
to block me from right-clicking to get the context menu; I want to turn off 
JavaScript just while viewing this site, but then I want to turn it back on")
Then again, support for URL-by-URL prefs (is this landing soon? or ever?) would 
resolve the case I just mentioned
This is a pretty cool idea and one that certainly warrants more discussion.  It's 

not likely to go into this version, though, so I'm resolving this as "LATER."  We 

can come back to it in the next round.
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → LATER
Reopening and setting milestone to Future. LATER is deprecated.
Status: RESOLVED → REOPENED
Resolution: LATER → ---
Target Milestone: --- → Future
*** Bug 38392 has been marked as a duplicate of this bug. ***
I'd also welcome this feature.  Having used a browser with
(basically) these options, I know how useful it can be.

Some comments however:

- Please add sound to the list
- Separate settings for background and foreground images
- Any links followed which are on the same site should inherit
  these settings.  Other links could be allowed to revert to the
  default settings (ie as set in prefs)
- Might also be good to add (inline) plugins to the list of
  victims.  Some of these can be damn annoying (the Crescendo
  Midi player springs to mind :)

Some addition discussion on this topic can be found in <a 
href="http://bugzilla.mozilla.org/show_bug.cgi?id=38392">bug 38392</a>.
Status: REOPENED → ASSIGNED
Reassigning from bdonohoe to hangas
Assignee: bdonohoe → hangas
Status: ASSIGNED → NEW
Target Milestone: Future → ---
Interesting, marking as future.
Status: NEW → ASSIGNED
Target Milestone: --- → Future
See also bug 20826, buttons to toggle images/java/javascript/etc.
Chaning the qa contact on these bugs to me. MPT will be moving to the 
owner of this component shortly. I would like to thank him for all his hard 
work as he moves roles in mozilla.org...Yada, Yada, Yada...
QA Contact: mpt → zach
Great idea!
Java should perhaps be in the list as well, and I'd like to see image animation
included.
Even better, eventually allow users to choose which prefs they consider
important for this toolbar -- a "personal prefs toolbar".
updating to new owner. sorry for the spam.
Assignee: hangas → mpt
Status: ASSIGNED → NEW
What do people think about making prefs changed on this toolbar only affect the 
page that you're on?

Would there be some visual indicatation on the icons that the type of content 
(images/javascript/etc.) they represent existed in the current page? For 
example, I want to know whether the current page has a javascript or not. See 
bug 42658.
Personally i'd like a small dropdown: Global | Domain | Site | Window | Page
but i'm not sure i can explain this to an end user.
*** Bug 42658 has been marked as a duplicate of this bug. ***
> What do people think about making prefs changed on this toolbar only affect
> the page that you're on?

I think it would be incredibly annoying, not to mention defeating much of the 
purpose of the `Images' and `JavaScript' toggles in particular (since once you 
turned those off again on a new page, it would often be too late).
Keywords: helpwanted
I put together a quick rendition of this at 
http://www.xulplanet.com/downloads/misc/prefbar.xpi.  It's still very basic, and 
contains numerous bugs (the largest of which being that it doesn't update itself 
when somebody else changes the prefs involved) but is fully functional, at least 
for the two preferences it currently includes.

This was designed for mozilla 0.8.1, so it probably won't work with the latest 
nightly builds.
Aaron Andersen: Great. But hang on... why isn't this a sidebar panel rather than
a toolbar?

An extra toolbar is always covering your content area. A "Hackers Sidebar" would
be really cool - all those useful prefs that power users like, and you can hide
the sidebar by double-clicking the grippy when you weren't using it. I had this
idea a while back but never got round to it. 

Also, the sidebar might make it in to CVS - I very much doubt an extra toolbar
will.

BTW, one feature - at the bottom, a text box for a pref name and another one for
the value, so people can change their favourite prefs without needing UI for all
of them :-)

Gerv
>Aaron Andersen: Great. But hang on... why isn't this a sidebar panel rather 
than
>a toolbar?

It's a toolbar because that is the title of this bug, "Preferences Toolbar, for 
most commonly used prefs."  It could just as easily be in the sidebar, and if it 
is agreed (by mpt et al.) that a sidebar panel would be best, I'll change it.
if you don't mind implementing a sidebar too for now, that'd be great, i think 
there's a separate bug for it.
A toolbar is less intrusive: you can keep it on all the time without taking away
much space from content.
A toolbar is _less_ intrusive? It would cover a good centimetre of the vertical 
content area and (given that pages are vertically oriented and screens are, for 
some reason, wider than they are high) vertical space is in short supply. It 
would also cover it permanently, whereas a sidebar panel could be flipped out at 
a moment's notice, or even left open (taking up horizontal space.)

Gerv
Bah, <sidebar/> and <browser/> need to live in a <bulletinboard/> so that 
people can make sidebar float or dock left/right.  Actually, if done right, 
toolbars could be docked or floated as sidebars...

How hard is it to make a panel that will display reasonably well in either a 
horizontal or vertical rectangle?  [Mozilla's box system unlike html seems to 
prefer fixed orientations and no optional wrappings]
Toolbar:
*   Can be easily turned on or off (through the `View' menu, or -- eventually
    -- the context menu for the toolbars themselves).
*   For a maximized browser window on an 800*600 display, takes away about
    16,000 pixels from the content area.

Sidebar panel:
*   Can be easily turned on or off (through the `View' menu, or by dragging the
    splitter).
*   For a maximized browser window on an 800*600 display, takes away about
    *75,000* pixels from the content area.

And that, my friends, is why it should be a toolbar rather than a sidebar 
panel.

Besides which, I suggest that the intersection set of those people who would 
like this sort of UI, and those people who dislike the sidebar in general, 
would be quite large.

If you want a prefs sidebar panel, please file that as a separate RFE. 
Thankyou.
I have completed the second version of my prefbar overlay.  This version is a 
lot nicer than the last one, and includes more preferences.  Any feedback, 
suggestions, bug, etc. would be appreciated.  Also note that the toolbar now has 
a context menu from which you can show or hide the different prefs on it.
Aaron: are you still using the URL
http://www.xulplanet.com/downloads/misc/prefbar.xpi ? Because the XUL there
seems to have blake's Value/Label disease. If not, could you upload your new
version somewhere? Preferably both as an XPI and raw files...

<bluesky>
Could you not have a context menu item "Add pref" which, when given the name of
a pref, determines its type and adds the name and a sensible type of control to
the bar? Also, the bar could scroll if it gets too long...
</bluesky>

Gerv
If you are talking about bug 70746, that is because this was written for 0.8.1, 
and as such doesn't have any XUL 1.0 stuff in it yet.  I have been too busy 
lately to keep track of which of the XUL 1.0 bugs have and have not been fixed 
right now.  When 0.9 comes out I will update this for whatever XUL 1.0 stuff is 
in by then.

The problem with user added prefs is that although we can check from nsIPref 
what type a certain pref is, there is no way (that I know of) to determine what 
the different values really mean.  The image loading pref for example, is an int 
pref, and takes either 0, 1, or 2, for off, server only, and on respectively.  
So although I could convert the image pref to a drop down box (to allow 
selecting of the server only option) I can not think of a feasible way of having 
the user add a new pref to the bar.  My current plan was just to include an 
extremely large number of prefs (with only a few turned on by default) and let 
the user choose which ones to include via the context menu.  (If you know of a 
pref that should be included that currently isn't, let me know)  However, if you 
can think of a better way of doing things I'd love to hear you ideas...
Re: user-added prefs. It's true you can't sanity-check them, but it would be a
"user's own risk" thing. I agree you should have a large number which you've
built in, certainly.

Gerv
It's not about sanity-checking, it's about how the user is going to be able to 
do this.  Take the cookie pref for example.  If I hadn't included that one 
already, there would probably be a user or two who would want to add it.  
However, in order to access a preference, nsIPref needs to have the prefstring. 
 Without looking at the source code for the preferences dialog, how is this user 
going to know that the prefstring is "network.cookie.cookieBehavior"?  And even 
if the user knew that, what then? The app would tell him that the cookie pref is 
an int pref.  But how is the user going to know what numbers mean what? (0 is 
off, 2 is on, and 1 is server only.)  

And after all that, what kind of a control should be used?  A textbox?  That 
wouldn't be very convenient, because  the user would have to constantly remember 
what numbers to use.  But any other control would require additional information 
from the user.  A checkbox (like I have now) would have to know what int value 
the checked and not checked states stood for (currently 2, and 0 respectively), 
and a drop down would require a list of different options, with an int value and 
label for each.  

If you've looked at the source code you know that my method of doing things 
isn't very pretty either, but the ui for it is clean and simple.  It just seems 
to me like any method for allowing the user to ad a pref to the prefbar would be 
extremely complicated and require more work on the part of the user than just 
opening up the .jar file and adding the new pref manually.

Remember that there are only a certain number of prefs in the product, and most 
of them don't need to be included here.  I see no reason why someone would ever 
need to change the homepage URL, or the number of days pages are kept in the 
history file using the prefbar.  Like I said, if there is a pref that I haven't 
included that you want or you think someone might want, let me know and I will 
add it.  But I don't think user-addable prefs would be worth the time and effort 
that would be required to make it work.

Aaron
OK, fair enough. I'm convinced. The prefs toolbar is not the place for this 
function, if it is indeed necessary. :-)

Gerv
I always thought it'd be nice to have a sidebar that let you edit ANY pref. 
Something similar to the way regedit works in Win32 where you have a tree view
and you can add, remove, and change settings with relative ease.  Perhaps this
could be a an advanced mode?  Or is this beyond the scope of this particular bug?

Please note that when using regedit in Win32, it is assumed that you are
reasonablly comfortable with what a setting is and what its possible values are
(just like when you edit prefs.js manually).
That's a different bug - bug 17199.

Gerv
Making this toolbar customizable should be filed as a separate RFE depending on
this one.
>Making this toolbar customizable should be filed as a separate RFE depending on 
this one.

Which should probably be dependant on bug 17199 also, because a fix for 17199 
would make it not quite so impossible to do a customizable pref bar.
*** Bug 82917 has been marked as a duplicate of this bug. ***
In a related note, my prefbar xpi is now updated for mozilla 0.9, and located at
http://www.xulplanet.com/downloads/view.cgi?catagory=applications&view=prefbar

All future updates will be at this location. As I said before, I could really
use some feedback on the design, included prefs, and/or backend implementation,
so if anybody has any comments, send them to kc7gza@hotmail.com (or post here,
if appropriate).

*** Bug 83021 has been marked as a duplicate of this bug. ***
The interesting question remains which aaron alludes to:
would prefs controlled by the toolbar only apply to the document being viewed 
or would they change the gloabl prefs?
While I am sure the author meant to change the global prefs, usability data I 
have seen before suggests that many users might not expect to change their 
global prefs but only to apply this fr the local document, or the session of 
the current window, because of the way it is presented (as a toolbar).

I think there is so much unused space on "status bar" and it could be used as a
place for some icons like:
[java on/off] [javascript on/off] [images on/off/current only] [cookies on/off/cur]

Just theese four buttons somewhere near to [online/offline] indicator and
[security] button.

Is it a different "bug"?
Yes it is a different bug, and a highly wontfixable one at that.

German:
>
> While I am sure the author meant to change the global prefs, usability data I
> have seen before suggests that many users might not expect to change their
> global prefs but only to apply this fr the local document,

That would be incredibly annoying, not to mention defeating much of the purpose
of the `Images' and `JavaScript' toggles in particular (since once you turned
those off again on a new page, it would often be too late).

>                                                            or the session of
> the current window, because of the way it is presented (as a toolbar).

Good point, I hadn't thought of that. Yes, it should apply only to the active
window, and settings from the last open window should be saved on exit. However,
I think the people who would use this feature in the first place could put up
with the prefs being global until that further enhancement was made.

--> XP Apps: GUI.
Assignee: mpt → blake
Component: User Interface Design → XP Apps: GUI Features
QA Contact: zach → sairuh
For anyone interested:
I have just filled Bug 87538 (enhancement) about preferences buttons on status
bar (buttons like online/offline and security buttons).

(Hoping it's not a dupe, I failed to find this in bugzilla)
*** Bug 89297 has been marked as a duplicate of this bug. ***
*** Bug 90309 has been marked as a duplicate of this bug. ***
*** Bug 20826 has been marked as a duplicate of this bug. ***
*** Bug 93604 has been marked as a duplicate of this bug. ***
Hi guys. :-)

I'm new to XUL and I've been following this enlightening discussion.

Would it be possible to do this toolbar at the BOTTOM of the browser, in the
place currently used for the "Status bar" (or whatever is the exact name for the
place
where the text 'Document: Done (x.xx secs)' is placer)?.

See the following screenshot for my view on how I'd love to see this implemented
(probably along with a small drop-down) to select between this and the default
status bar behavior. :)

Regards
Fernando

Fernando: see bug 87538 (apparently you failed to read previous comments)

Your screenshot eats almost all of the status bar. It wuold be better to have
just small buttons like security button on the right to eat just a small space
from the right side of status bar. There's no need to have text and checkbox on
preference button - just the change of shape/color would indicate state of
button (like security and online/offline buttons does).

f.e. Java button could be a cup of coffee:
   when turned OFF -> empty grey cup
   when turned ON  -> colourfull cup with steam from hot coffee
(with tooltips "Java: ON" and "Java: OFF" when mouse over)

More debate on preferences buttons on status bar should go to bug 87538, it's
OFFTOPIC here.
Blocks: 93638
Blocks: 96654
Having read this entire thread, it seems this proposed feature is aimed only at
developers.  I don't see the case for providing this to millions of end users
who would only be confused by it and don't have a pressing need to be flipping
these values more than once in their lifetimes.  

If this developer tool gets implemented, it should be distributed as such - a
separate xpi that can optionally be installed by developer users.  Aaron
Andersen has demonstrated that this is a sufficient distribution mechanism for
those who want it.

Since this bug is proposing a permanent change to the UI that is targeted at a
very small user group, I suggest that it should be marked WONTFIX and those who
want this feature should build it as a separately available xpi.
selmer is correct; IMO this should not make it into the main Mozilla
distribution. However, if leaving this bug open would help development of the
XPI, that's not a problem.

Gerv
I thought that this was a feature a lot of users might like: e.g. leave Java off
until they go to a site that really needs it leave JS on until they hit a site
that keeps popping up windows, then turn it off right then; leave custom fonts
on until they get to a page that's unreadable.  I'm not sure what any of these
have to do with whether someone is a developer; if anything I would have thought
that newbies (those who don't understand the prefs dialog) stood to benefit the
most.
The fact that these features are useful does not necessarily mean we need a new
toolbar. Computer monitors are vertical-space-poor and horizontal-space-rich
compared to how people like to read documents. We should avoid taking more
vertical space than is absolutely necessary.

Note that the <LINK> element navigation toolbar will soon be checked in - this
is something that makes us more HTML 2 (!) compliant, and is potentially useful
to all users. If we are to have another toolbar, that is a much better
candidate, because widespread deployment will encourage adoption of <LINK>. A
similar argument cannot be made for the prefs toolbar.

The fact that mozilla.org perhaps does not do as good a job as it might of
making people aware of all the cool additional stuff they can install is a
separate problem.

Gerv
I agree w/ Gerv that using more horizontal space might not be a good idea, but I
think Akkana is right in assuming a high number of potential "frequent pref
changers". In my environment I've seen recently quite some people trying Galeon
for the first time. They liked the UI speed, and *all* of them liked the
"Settings" menu to quickly switch on/off JS, Java, proxy, imgs, and so on. It
appears to me that the Galeon people hit the right nerve with that menu, and I
presume that most supporters of this bug could live with such a solution.
I'm not saying that this UI should not be more prominent, my point is merely
that a toolbar is the wrong place for it.

A menu would also have to be removed by all distributors whose target audiences
were not hardcore techies (What Mozilla's target audience is, in UI terms, is
still a matter for debate.)

This is why I continue to suggest that the best place for this UI is a sidebar
panel. It can be installed with a single click on a link, reduces horizontal
rather than vertical space, and can be put away easily when not needed.

Gerv
Perhaps my use of the word "developer" is too charged.  I said that because I
hadn't seen any evidence that this was driven from an analysis of actual
end-user usage patterns.  I agree with Gerv that a sidebar panel is the best way
to address this for now.  If the sidebar panel becomes wildly popular, then that
would justify giving it greater precedence in the UI later.

In any case, I don't agree that this toolbar should become part of the standard
product at this time. 
I won't argue the inclusion or not (especially in the Netscape client; Mozilla
folks can make their own decision) or the priority (which is a function of when
someone has time to make it happen).  But let's please not morph this toolbar
request into a sidebar request: see mpt's comments of 2001-04-24 08:35 for why not.
As per mpt's original bug description, this would be a toolbar that defaulted to
being turned off.  Therefore the toolbar is not going to waste any verticle
space unless the user decides to turn it on.

Since there is a functional toolbar solution, why discard it?  If some people
would prefer a sidebar solution, then open a new bug and let someone come up
with a sidebar solution, but do not ignore the users who would prefer the toolbar.

I also do not understand the opposition to having this toolbar included in the
standard build of Mozilla.  The resource overhead of this toolbar is minimal and
it defaults to being off.  I do not see how inclusion of this toolbar would
cause any problems for anyone who does not want it enabled.  However inclusion
would be very convienent for those who are interested in using it; otherwise it
has to be reinstalled each time a new Mozilla build is used AFAIK.  Also many
users who would like to have this feature do not even know Aaron's toolbar
exists so how would they know to download and install it?
I filed this RFE because:
*   there are some prefs which (contary to selmer's assertion) advanced users
    want to turn on and off quickly, and I have seen many comments in newsgroups
    and Web discussion forums to that effect;
*   unlike with 3.x or earlier, when Mozilla's user base was (on average) much
    more technically-minded, such options do not deserve a top-level menu of
    their own;
*   such prefs could be toggled much more quickly from a toolbar than from the
    prefs dialog, even if the toolbar was hidden initially;
*   such a toolbar could be off by default, and access to it would be very
    unobtrusive for those who weren't interested in it (second from bottom of
    the `Show/Hide' submenu, and third from bottom in the context menu for any
    toolbar).

The longer Mozilla lacks something like this (in the default distribution), the
more duplicates this bug will collect, and the more potential contributors will
use browsers like Galeon, iCab, or Konqueror rather than Mozilla.
> Since there is a functional toolbar solution, why discard it? 

No-one is suggesting discarding it; my assertion is that it should be an XPI.
And yes, we need a page of "cool stuff to install in your copy of Mozilla", and
I've asked several times in the newsgroups for someone to write one.

There's a load of cool stuff that Mozilla can have added to it; in each case, we
have to ask whether it should be in the default build, or whether it should be
an XPI. There are no criteria for this that I know of - it's a case-by-case
thing. But the question is not "why shouldn't it be in", it's more "why
shouldn't it be an XPI"? 

Gerv
Status: NEW → ASSIGNED
Target Milestone: Future → mozilla1.0
I suggest an obvious solution to getting people's attention to cool-addons with
a new default installed Sidebar for "Mozilla Add-ons"..

xul patch prefbar from xulplanet has problems with javascript not keeping the
setting for JS on/off also there is problems with the bookmarks in prefbar
folder because of the patch, so in essense it is not working on newer builds
since patch was created where after awhile the user only sees the first 3
options in the bookmarks toolbar menu.  Which has generated bug reports of
bookmark problems.

http://xulplanet.com/downloads/view.cgi?category=applications&view=prefbar

-dennis
Adding self to Cc, I love this thing, but I hate reinstalling it for
every version.  When can we get this thing into the distribution?
I don't mind if it's turned off by default; View->Show->Preferences
would be a *lot* easier than redownloading it every time.

> A toolbar is _less_ intrusive?

Most definitely.  

I *hate* the sidebar and want it to go away forever.  Toolbars
are quite useful, and the amount of space they take up will
eventually be improving per bugs 48926 and 15144; whereas, the
sidebar consumes an unconscionable amount of space and AFAIK
there are no plans to change this and probably never will be, 
since the only people who like the sidebar at all are people 
who like cluttered screens. 

> My current plan was just to include an extremely large number 
> of prefs (with only a few turned on by default) and let the 
> user choose which ones to include via the context menu.

Like this plan. 

> feature is aimed only at developers.  I don't see the case 
> for providing this to millions of end users who would only 
> be confused by it and don't have a pressing need to be 
> flipping these values more than once in their lifetimes.  

True for some preferences, but extremely false for things
like Java and Javascript, that *need* to be off to make some 
pages usable, and those are pages that tend to be viewed 
mostly by end users, NOT developers.  

> The fact that these features are useful does not necessarily 
> mean we need a new toolbar. Computer monitors are 
> vertical-space-poor and horizontal-space-rich compared to 
> how people like to read documents. We should avoid taking 
> more vertical space than is absolutely necessary.

A separate issue entirely; see bugs 48926 and 47418, 
among others.  

Furthermore, your claim that monitors are rich in horizontal
space and poor in vertical space is fairly irrelevant in the
light of web browsing; it is no problem to scroll vertically
after reading a paragraph; the need to scroll horizontally
every single line is *seriously* annoying.  Most web pages
designed for 800x600 can be viewed comfortably at 800x400
but degrade very ungracefully at 640x480.  In summary, 
Toolbar=good.  Sidebar=evil.

> A menu would also have to be removed by all 
> distributors whose target audiences were not 
> hardcore techies 

No offense, but you must surely be smoking crack.  
If you read n.p.m.wishlist (or search Google), you 
will see Java and Javascript preferences in particular 
get *regular* requests there for a place on the toolbar, 
and many of the people making these requests are not 
sufficiently technically-oriented to comfortably use 
Bugzilla, let alone "hardcore techies".

> This is why I continue to suggest that the best 
> place for this UI is a sidebar panel. 

The best place for the sidebar is on another planet.

Toolbars also can be easily put away when not needed,
and they take a lot *less* space.  A *lot* less.
Target Milestone: mozilla1.0 → Future
*** Bug 108380 has been marked as a duplicate of this bug. ***
as part of the toolbar customization system, which is on the (event) horizon,
this bug might get solved.  users will be able to create custom toolbars and add
hidden features, from other components, or from prefs.
*** Bug 112421 has been marked as a duplicate of this bug. ***
The Preferences Toolbar does not install correctly in recent
builds.  I can't get it to work.  Is this just me, some other
change to my system, maybe, or can someone confirm that this
has bitrotted?
> does not install correctly in recent builds.  

Oddly, I have it working again in 2001120603; apparently, in
addition to restarting Mozilla after installing it, I also
had to restart Windows, but now it works.  This is really
odd, because the same procedures did _not_ get it working
in 0.9.6, for example.  The only other thing I know about
that I've done to Mozilla ad interim is install a silly 
little plugin that opens the CD-ROM drive.  Anyway, I have
my prefs toolbar back, and I'm happy, but I fear what will
happen next time I upgrade Mozilla...  
The solution for this has been out now for seven months. What possible reason
can there be not to release it?! 

I'm for putting the toolbar out now. I'd default it to visible, too. Who doesn't
occassionally want to turn off popups or javascript? [A: people who don't know
they can turn it off]. 

I'd say goto and setting of the homepage should be added to this one as choices,
since these are truly preferences. I might even hide the personal toolbar if I
could have a home button on this one. Another minor suggestions - the context
menu of all toolbars should have a "hide toolbar" option.


> The solution for this has been out now for seven months. 
> What possible reason can there be not to release it?!

Read Gerv's comment (#59).  I disagree with his reason, but
there it is.

> I'm for putting the toolbar out now.
  
So vote for bug 111714.
  
> I'd default it to visible, too. 
  
I don't frankly care whether the default is hidden or visible.
I just want to not have to install it again every time I
download a new version, or every time I install the browser on
another computer.  

Actually, when I think about it, the prefs toolbar should
probably be hidden by default, on the grounds that people who
don't bother to look under View->Show/Hide are unlikely to
care whether various preferences are turned on or off (since,
indeed, whether toolbars are visible or hidden is in itself a
preference, from the user's perspective).  Also, the default
state should IMO try to be similar in appearance to version 4
browsers (although by that reasoning the sidebar should be
disabled by default and the classic theme used by default, so
perhaps this reasoning is inconsistent with the develpment
team's philosophy).

> Who doesn't occassionally want to turn off popups or
> javascript? [A: people who don't know they can turn it off].
  
popups are a bad example (and a separate bug), but there are a
lot of people who occasionally want to turn off (or
occasionally want to turn on) Java or javascript, and there
are a few people who don't usually leave cookies turned on but
need for one reason or another to turn them on occasionally.
And then there are the few like me who normally leave page
colours disabled but want occasionally to turn them on.  But I
think the largest number of people would mostly want the java
and javascript checkboxes.

> I'd say goto and setting of the homepage should be added to
> this one as choices, 
 
Is this really something you want to change with any
frequency?   Don't most people keep the same homepage for days
or weeks or even months at a time?  Stuff like that, it's no
big deal to drag out the Preferences dialog.  The toolbar is
particularly nice for stuff you want to change frequently (as
in several times a browsing session).  
  
> I might even hide the personal toolbar if I could have a
> home button on this one. 

I think changing which buttons are on which toolbar should be
reserved for bug 15144.  This bug is only about making
preference buttons available; navigation buttons are unrelated.
  
> Another minor suggestions - the context menu of all toolbars
> should have a "hide toolbar" option.

Interesting suggestion, but not related to bug 38521.  Please
make this comment in a more appropriate location.  


In case anyone here hasn't noticed, someone files bug 111714, "Integrate
Preferences Toolbar into the main Mozilla tree" a while back, and there has been
some talk in that bug about whether or not this should ever be fixed.  One of
these bugs should probably be marked duplicate or dependant on the other, but
since the discussion seems to have moved over there, you may want to move your
votes and CCs as well.

Aaron
I don't think bug 111714 is a duplicate of this bug per se,
but it certainly should be considered dependent on this bug.
Blocks: 111714
Taking.  It doesn't look like this is actually going to get in, unless it is
done so as part of bug 49543.  However, I would be willing to turn my xpi addon
into a patch of the occasion arises.  See comments in bug 111714.
Assignee: blaker → kc7gza
Status: ASSIGNED → NEW
Status: NEW → ASSIGNED
*** Bug 131518 has been marked as a duplicate of this bug. ***
Bug 131518 is a RFE to put freq prefs into the main tree and has nothing to do
with toolbars or sidebars.
Instead of calling it the "Preferences Toolbar", why not give it a more fancy
name, such as the "Power Toolbar" for power users. That would make it attract
more hackers! :)

adding self to cc list
I hate toolbars and also the sidebar because they waste a lot of display area.
I prefer menus with command keys.

i.e. ctrl-J / cmd-J could be used to toggle JavaScript on and off.
The menu item for this feature could be "Tools" -> "Web Development" ->
"JavaScript on" / "JavaScript off"
Yep, toolbars as in Microsoft profucts are senseless. Although, _good_ toolbars
(see CorelDraw!'s Property Bar) have an obvious advantage of not only letting
you configure many switches at once without stumbling through menus, but also
letting you see the status of multiple switches at a single glance.

Although, there definitely SHOULD be keyboard shortcut for each of those settings.
Aaron,

Would it be possible to modify your toolbar xpi to include the ability to
hide/show the toolbar by using a hotkey? (I'm thinking about F12, which is
currently not used for anything else).

I'm asking for this because while I could "minimize" the toolbar with a single
click, it still takes too much vertical space (even while I'm running at
1024x768) during normal browsing, so it would be MUCH nicer being able to press
F12 to bring it up, change options, press F12 again and hide it.

Tell me what you think.

Regards
Fernando
That makes much sense. But then, why not put it in the sidebar? Can a sidebar
tab do this, or does it not have enough permission?
Is it possible to hide a sidebur with a single hotkey? Usually, sidebars occupy
much more screen space (150*700) than a toolbar (1024*40).
You you pull down you View -> Show, you'll see that the sidebar has F9 as its
hotkey for going away.
Reply to comment#81:

Yes, F9 hides/shows the sidebar. And in mozilla 1.0rc2/netscape 7.0rc1 and 
higher, pressing [F11] toggles between normal and "full screen" mode (a la IE). 
Very, very nice.

That's why I think adding a hotkey to show/hide the preferences toolbar using 
F12 would be great, as F12 is currently not used for anything else.

And about the idea of making it a sidebar instead of a toolbar, I think it was 
discussed before, but anyway my $.02 is that sidebars are great for what they do 
best: displaying customized web content and/or xul applets like jabberzilla etc.

I don't think it would be nice to "pollute" the sidebar with browser 
preferences. In other words, I don't think I'd like to see browser configuration 
dialogs (or toggles) moving from the browser interface into the sidebar.

I'd vote for leaving it as a toolbar easily hidden by pressing F12 when not 
used.

Just my $0.02
Fernando

I believe F12 is used to open/close the cd rom tray on Mac OS X.
*** Bug 122007 has been marked as a duplicate of this bug. ***
I have hooked up F8 as the prefbar show/hide key, because it isn't use by
mozilla or any OS that I know of.

If there are issues with the F8 key, please enlighten me...
Alias: prefbar
If you want your shortcut key to work on Mac (or if you want to keep Mac people
from flaming you), don't choose F8. Function keys are generally reserved on Mac
for user programmability.

Check the page at
http://www.mozilla.org/projects/ui/accessibility/mozkeyplan.html to find
available keys, and get back to us.

Also, the FAQ for choosing a key is at 
http://www.mozilla.org/projects/ui/accessibility/mozkeyintro.html
I still think it has to be an F key.  The whole point of having an accell for
this is so that one can access it with one click.  I think an order of magnitude
more people are going to want to quickly show and hid the prefBar then want to
quickly show and hide the sidebar, and yet the sidebar has an F key.  (Even on
the Mac, as far as I know.)   If we assign this Ctrl+Shift+H it's not going to
be much of an improvement from View->Show/Hide->Preferences Toolbar.
Comment #88 wrote
> If we assign this Ctrl+Shift+H it's not
> going to be much of an improvement from
> View->Show/Hide->Preferences Toolbar


Actually Ctrl+Shift+H is short for Go->History on MacOS X.

So, you don't want to use that shortcut.

Also, I *never* use Go->History, and I *frequently* use Ctrl+Shift+H so at least
in my opinion, a three-key keystroke is *much* better than a menu item, even
when that menu item is at the root level of its menu. So, I would disagree with
your claim that a 3-key keystoke is not much better than a menu item.


> I think an order of magnitude more people are going to want
> to quickly show and hid the prefBar then want to quickly
> show and hide the sidebar,


Just curious, but how do you arrive at that estimation? In my experience, the
sidebar is used by most mozilla users, while the prefs toolbar is used only by
"geeks". Most users don't understand their prefs well enough to want to muck
with them.

I know many many users who use the sidebar regularly and show/hide it because it
takes up a fair chunk of screen. Some folks are web developers and have
reference materials in their sidebar. Many more folks hold search results in
their sidebar. An intermediately-sized group use their bookmarks and/or history
from their sidebar as a surrogate start page. These users show/hide their
sidebar as an integral part of their web browsing.

I know less than ten users who use the prefs toolbar (counting myself). They use
it for specific sites where their normal prefs are not ideal. Occasionally they
find a new site where they need to use it. The toolbar is small enough that I
have not heard one complaint from any of these users about the space it takes
up. I think that even if there were a keystroke to show/hide the toolbar, most
of these users would just leave it visible all the time. If they did show/hide
it, I don't think they would do so more than they do with the sidebar (with the
exception of one user in the toolbar-using group who doesn't use the sidebar at
all).


> and yet the sidebar has an F key.
> (Even on the Mac, as far as I know.)


Confirming for you: yes, even on the mac.

...but I'm still thinking more users show/hide the sidebar with greater
frequency than would show/hide the prefs toolbar. I'd be curious to hear why you
think otherwise. Is this based on your own browsing habits, or on observation of
other users (what sort of users were they?), or on a usability study?


> I still think it has to be an F key.


There are only so many F keys. Assuming mozilla has the "right" to occupy those
F keys (mac tradition is that mozilla should leave those to the user who knows
better what 15 things they find most important), are you so certain that your
feature is more important than any other 15 features?


> The whole point of having an accell for this
> is so that one can access it with one click.


(keystroke, I'm assuming you meant, rather than click)

Hmmm... is that true of *every* accell, or just this one? If *every* accel, then
 we're going to run out of keys. If just this one, why is it that *this*
feature's accel needs to be single-keyed, but others do not?

Looking at what's available, I'd suggest control-T or control-J.
Personally, I like control-J

    left pinky to control, index finger on home row hits J.
    very easy and comfortable (more so than most F keys, for me)

    I ususally want to turn on/off _J_ava or _J_avaScript

control-T is less ideal for me because it's harder for my right pinky to get to
the control key (that could just be me), but I like the T character as standing
for "turn on/off" "toggle" or even "toolbar".

What do you think?

-matt

Dude, where have you been? Download a recent Mozilla, press Ctrl-T, and realise
that you really can't have it for the Preferences toolbar ;-)

Gerv
in the language of
http://www.mozilla.org/projects/ui/accessibility/mozkeyplan.html

that's accel-T. On my mac, that's command-T.

control-T doesn't do anything on my machine.

-matt

Re: comment 88

Those of us who can't/don't use high screen resolutions don't have space to give
a sidebar. The very first thing I do after create new or migrate profile is F9,
and in first pass through prefs untick "open search results in sidebar".
> > I think an order of magnitude more people are going to want
> > to quickly show and hid the prefBar then want to quickly
> > show and hide the sidebar,

> Just curious, but how do you arrive at that estimation? In my experience, the
> sidebar is used by most mozilla users, while the prefs toolbar is used only by
> "geeks". Most users don't understand their prefs well enough to want to muck

Obviously, I was referring to only those users who had the prefbar installed
(and was based on the hundred or so feedback emails I've been sent regarding the
prefbar and what people want out of it). 

Since the prefbar is not likely to be in the default builds any time soon, any
shortcut key assigned to it won't do anything to users who don't have it on
their machine.  If we're talking about actually checking this in, well then
that's a whole different story...

The reason I want the prefbar to have a one key shortcut is because of the way
people use (or will use) the prefbar.  Nobody wants to have to give up the
vertical screen space to have it open all the time.  Instead they want to say
"Oh look, this site has an unreadable color scheme.  Open prefbar.  Turn of
colors.  Close prefbar." or "Oh look, this site blocks non-IE browsers.  Open
prefbar.  Change user agent to IE.  Close prefbar." and get on with their life.
The whole thing wouldn't last more than six seconds.

If mac users really do value their F keys that much, they don't have to use the
prefbar.  My guess is that any mac person who cares enough to install this thing
is going to find it much more useful than whatever "user macro" he could have
otherwise assigned that key.

Aaron
As for this whole function key debate (mpt is trying to force caret browsing
hotkey to something other then F7, and now the Tools menu looks awful because
the hotkey name is almost longer then what it actually does), if MacOS is so
silly as to bind TWELVE keys on their keyboard to global OS functions, so be it.
But these keys on Windows and Linux are intended for APPLICATION use. If we end
up with ctrl-shift-something for stuff like this that's important to be able to
hit quickly, I'd be upset. Mac can have the crummy hotkey. Give Windows and UNIX
users something reasonable.

What about having shift (or alt, ctrl, or command) + numbers do on mac what F
keys do on other OSes? Alt-1 through Alt-= is a much better set of 12 hotkeys
then forcing EVERYONE to use ctrl+shift+alt+meta+hyper+p for pref bar.

I can hit "alt-e, e" pretty damned quick. If pref bar isn't super easy to pop up
and down, it may as well not exsist.
Depends on: 153645
Um, this bug is in no way dependant on bug 153645.  Removing dependancy.
No longer depends on: 153645
*** Bug 155450 has been marked as a duplicate of this bug. ***
Count me among the "frequent pref changers" who want to do preference changing
while doing regular (ie non-developer) browsing. I want to turn off pop-ups as
the default and then turn them on briefly on a page that needs them in order to
pop up a dialog that I really want to see. Also, on a page that has fonts that
are too small or background colors too similar to the font colors (what brain
disorder afflicts the web designers who do that?) it would be helpful to be able
to _rapidly_ change some settings. So this is not just a feature for developers. 

I also support URL-specific preferences. It would be good if the URL
specification supported some wild carding of URL patterns. Like *.mysite.com or
www.mysite.com/anythinghere/* to specify areas of sites that should have
particular preferences. 

Also, "apply preference change to current page only" would allow one to avoid
having to reverse the preference when done viewing a page. 

Another idea: Right click on a page and choose an option called "Alternative
Preferences". Moz would then pop up a list of user-defined named preference sets
(a few sets could be included). Then click one one of them to choose which
preference set to apply to the current page. What is important here is that the
preference sets should be able to be incomplete lists of preferences. That way
one could define a set that just changed background color without having to copy
over all the other setttings and therefore without having to maintain the
preference sets in sync with each other for all the prefs for which they have
common values. 

So:
   1) Named preference lists.
   2) Preference lists that are subsets of all possible preferences.
   3) Assignable preference sets to 
      A) Current page
      B) Current Tab
      C) Current Window
      D) URL Patterns
      E) Permanent Global (ie assign a named preference list to the main default
preference list)
   4) Right click choice to choose named preference list.
      A nice twist here would be the ability to have the choices be cumulative
since the preference lists would be subsets. 
   5) Right click choice to revert to default preference list.
   6) Save current set of preferences as default.


this is purely an issue of sematics i have with the summary of this bug, 
because i agree with some of the proposed ideas, but refering to it as a 
'preferences bar'  for me, defeats the purpose and concept behind 
preferences.  sorry if i am being a picky UE guy, but if we called it 
something like 'advanced user bar', 'custom toolbar' or  'formatting bar'  i'd 
feel better. because if there really are features out there hiding in prefs, 
they should be surfaced more easily, and we shouldn't be calling them 
prefs anymore.

as i mentioned earlier, toolbar customization would solve this, because 
one of the plans is to offer pre-packaged custom bars that would be 
available for each component.   in which case this bug could be more 
about what one of the 'default custom user bars' might look like for 
browser.

so imagine a dedicated content view (like in mac ie) for toolbar 
customization that would allow you to edit your current toolbar, or choose 
from a pre-arranged, advanced set of toolbars which cater to different 
types of users.




this is purely an issue of sematics i have with the summary of this bug, 
because i agree with some of the proposed ideas, but refering to it as a 
'preferences bar'  for me, defeats the purpose and concept behind 
preferences.  sorry if i am being a picky UE guy, but if we called it 
something like 'advanced user bar', 'custom toolbar' or  'formatting bar'  i'd 
feel better. because if there really are features out there hiding in prefs, 
they should be surfaced more easily, and we shouldn't be calling them 
prefs anymore.

as i mentioned earlier, toolbar customization would solve this, because 
one of the plans is to offer pre-packaged custom bars that would be 
available for each component.   in which case this bug could be more 
about what one of the 'default custom user bars' might look like for 
browser.

so imagine a dedicated content view (like in mac ie) for toolbar 
customization that would allow you to edit your current toolbar, or choose 
from a pre-arranged, advanced set of toolbars which cater to different 
types of users.




*** Bug 158452 has been marked as a duplicate of this bug. ***
*** Bug 158452 has been marked as a duplicate of this bug. ***
*** Bug 111911 has been marked as a duplicate of this bug. ***
there's the prefs toolbar XPI on xulplanet and adding buttons to diable CSS and
Plugins shouldn't be that difficult to be added, or? So what's the problem with
this?
*** Bug 160311 has been marked as a duplicate of this bug. ***
http://www.xulplanet.com/downloads/view.cgi?category=applications&view=prefbar
Cool feature, 

i mentioned this to an opera user
he laughed and in Opera pointed to:
File, Quickprefs F12
with submenu of checkbox menu items.  

Always got to do comparisons when designing GUIs.  i asked what the F12 shortcut
was for and it pops a context menu under the current cursor position.  A quick
scan of the comment already seem to want to use F12 for this (although ill bet
there are window managers and system programs that want the F keys and that
applications are supposed to avoid using them).  

I dont have opera so sorry i cannot do a screenshot for you.  I assume it was
the latest version of Opera.  

This seems to me like probably the best interface to solve this problem. 
(biased: i never use the sidebar).  Maybe there is another bug about a differnt
inteface solution to this problem or maybe this bug should have it summary
changed to be more generalised?  

I had considered doing something with javascript bookmarks (afaik you can change
pref using a javascript protocol bookmark aka bookmarklets) so that i could
simply add these items to my Personal toolbar, but that would not allow me to
have checkboxes.  

(Sorry if any of this is redundant, i did quick scan of the comments but i dont
have time to carefully read them all and i really wish there was some way for
maintainers to summarise bug reports, 100+ comments is really a bit too much).   

http://www.squarefree.com/bookmarklets/zap.html

did a quick search on this page for the word zap so i am geussing no one
mentioned these useful bookmarklets (again sorry if this is redundant)

add them to you bookmarks and your personal toolbar folder as an alternative
solution to this problem.  

the URL field was empty so i add the link there too, feel free to change it,
probably be better if the a link to that other toolbar was there.
URL: http://www.squarefree.com/bookmarklet...
Sorry, for being redundant, but using a popup like Opera's Quick Preferences
really is the *only* thing that makes sense. A popup has more space for prefs
than a bar, it doesn't take up space during normal browsing. In Opera I press
F12 to call the popup and click on the Javascript entry and I'm done. Besides, a
menu is more flexible than a bar because it can not only have toggles but also
radio button groups. Opera uses one in Quick Prefs to select the User Agent it
will present to the server. Very useful.
I believe F12 is used in OS X to eject the CD ROM.
Unforunately, it's not that easy to come up with keyboard shotcuts these days.
However, whatever we do, we will need some kind of keyboard shortcut for quick
prefs.
Prefs pop-up dialogs and shortcuts: Well, another way to make it possible to
bring up the Prefs dialog would be with a mouse right click (or whatever the
equivalent is on Mac) to bring up a list of options over a window. Right now
right click does bring up a list of options. Just add a Quick Prefs entry to
that list. That'd be really helpful because browsing is a very mouse-intensive
activity and so most people tend to be mousing when browsing. 

BTW, I'd love to be able to right click over an image and have one of the
choices on that pop-up be "Stop animated play" in order to stop some flashing
icon from flashing. In other words, a few of the really common prefs changes (eg
stop an animated image or stop all Javascript on this page) ought to be avaiable
without even having to go as far as bringing up the full Commonly Used Prefs
dialog box. 
With the release of Mozilla 1.1 (OS/2), the "popups" portion of the preferences
toolbar has stopped working for me.  It worked fine in the development versions.
 Anyone else?
I just uploaded the update to my Preferences Toolbar at
http://www.xulplanet.com/downloads/prefbar/.  I think it is a big improvement
over the original.  Everybody go download it and tell me what you think (over
email, so we don't make this bug any longer than we have to.)


Aaron
URL: http://www.squarefree.com/bookmarklet... → http://www.xulplanet.com/downloads/pr...
Link to screenshot of Opera6 Quick Prefs menu 
http://matrix.netsoc.tcd.ie/~horkana/dev/Opera6-QuickPrefs.png

just the menu on its own, it is located under File, Quickprefs.  If you were to
do something similar in mozilla it would make sense to put it under Edit beside
Preferences...
*** Bug 170956 has been marked as a duplicate of this bug. ***
*** Bug 172599 has been marked as a duplicate of this bug. ***
> Nobody wants to have to give up the vertical screen space to have it open
> all the time.  

Just for the record, I leave it open all the time, and doing otherwise seems
silly to me, because I use the thing so often...  it is more important to me
than the personal toolbar (even though I use that extensively also) and the
tiny amount of space it takes up is worth less to me (by a fair margin) than
the time that would be required to turn it on and off all the time.

I could live with a toplevel menu, but something buried underneath 
Tools->Web Development or someplace like that would be an inadequate
substitute.  The sidebar, as I said, is Not For Me.  The toolbar is
the ideal solution.

Since it does not look as though the toolbar will be accepted into the
main tree, even as an optional package turned off by default, how hard
would it be to get it to install into the user's profile chrome, so that
it wouldn't have to be redownloaded every single upgrade?
Not sure if this is the right place to report this, but:
The "Kill flash" button does not work on some pages, notably the flash
advertising at http://linuxtoday.com/.
Not sure if this is the right place to report this, but:
The "Kill flash" button does not work on some pages, notably the flash
advertising at http://linuxtoday.com/.
Product: Core → Mozilla Application Suite
Assignee: aaron → nobody
Status: ASSIGNED → NEW
Priority: P3 → --
QA Contact: bugzilla → guifeatures
Target Milestone: Future → ---
See bug #258881, which requests that PrefBar be incorporated as a standard browser feature.  See also the corresponding Mozdev 7670 at <https://www.mozdev.org/bugs/show_bug.cgi?id=7670>.
Component: XP Apps: GUI Features → UI Design
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: