Ability to add/remove toolbar buttons (customize toolbars)

RESOLVED FIXED in Future

Status

()

P5
enhancement
RESOLVED FIXED
20 years ago
9 years ago

People

(Reporter: CodeMachine, Unassigned)

Tracking

(Blocks: 1 bug)

Trunk
Future
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

20 years ago
I'm not sure who this should go to, but here goes.

XUL is really great and everything, but I don't think end users are going to
edit it.

It would be possible to include XUL editors that allowed you to add and delete
stuff from the chrome.  However, once a button is deleted, it would be gone from
the XUL!  Ideally it should stick around so you could readd it.

So, preferably, the XUL would define a whole heap of toolbar buttons, and the
user would then choose which to display.

It seems like this might work as a stylesheet, but whether you'd want to
generate a stylesheet I don't know.

But anyway, the gist of this is for a way to declare a button in XUL and
required or optional (most should be optional), and provide the ability to
delete/add these optional buttons.  Expert chrome could be loaded with lots of
useful buttons, but only some might be useful to the user.  Hence, you could get
some useful customization without touching your skin.
(Reporter)

Comment 1

20 years ago
Bug #15148 discusses a use of this.
you could store a list of buttons in RDF the same way that huge list of sidebar
panels in the Sidebar Customise dialog. (which doesnt display anymore o_O) Then
you could use a UI like that to add buttons (Actually, that sidebar customise UI
could be used in both places)

Updated

20 years ago
Assignee: trudelle → hyatt
Priority: P3 → P5
Target Milestone: M14

Comment 3

20 years ago
reassigning to hyatt for consideration post-beta
(Reporter)

Comment 4

20 years ago
Does this mean the XUL is not changed?  What I'm ideally looking at is making
this totally independent of XUL.  So all toolbar buttons could be removed and
readded, just like all toolbars can be collapsed and the setting should be
remembered, all without requiring JavaScript, and with no necessity to change
the skin.
(Reporter)

Updated

20 years ago
Summary: Toolbar button repository. → Ability to remove toolbar buttons
(Reporter)

Comment 5

20 years ago
This would be great for resolving the "Go" button dilemma, where some people
want it and some don't.

I suggest the ability to add/remove buttons could be done via a right click
anywhere on the toolbar (except those places that have their own right click),
and a specific remove by right clicking on the button.

Updated description.

Comment 6

20 years ago
A Turn Images On & Off button on the toolbar would be nice for those of
us not on highspeed connections. Instead on being buried in the Edit /
Preferences/ yadda yadda yadda diggin Tab just to turn a simple feature
on or off seems a lil' bit pre-historic these days me tinx :)

Updated

20 years ago
Target Milestone: M14 → M18

Updated

20 years ago
Summary: Ability to remove toolbar buttons → Ability to add/remove toolbar buttons

Comment 7

20 years ago
Adding myself to the CC: list if you don't mind 8-)
(Reporter)

Comment 8

20 years ago
Something you would also want is the capability of having buttons that are
initially removed.

Comment 9

20 years ago
Has anyone seen Sjoerd Visscher's post about this today
(news://news.mozilla.org/7vigbb%247q31%40secnews.netscape.com)?

It's pretty cool.  It's not the standard "Customize Toolbar" dialog that a lot
of applications have, but it's really a lot quicker than that.  The only thing
that it's really missing is the ability to re-position existing toolbar buttons.
Does the menu object support drag-and-drop, kind of like IE's Favorites menu?
Then all of the customization could be done from this simple menu, and an
instance of the menu could be duplicated under, say, the View menu.
If I understand Matty's suggestion correctly, he's proposing a hard-coded set of

buttons in the/each toolbar, each of which will have its visibility or

invisibility set by a CSS flag.



In my opinion, this would be a bad implementation of this feature, as (a) Mozilla

would be wasting time and memory by loading data about buttons which weren't ever

being used, and (b) it wouldn't make adding custom-function buttons any easier

because you'd still need to add them to the XUL by some other method.



What would perhaps be better would be a single registry of buttons. Then all

these buttons could be shown, on demand, in a Customize window (like the one in

MS Office), and the buttons could be dragged to/from toolbars *or* menus.



Of course there would be `Add ...' and `Delete' buttons in this Customize window,

for installing your own buttons. And you might want to extend this so that, for

example, useful string gadgets could be manipulated like this as well (with the

proviso that they could only appear in toolbars, not in menus).
(Reporter)

Comment 11

20 years ago
> If I understand Matty's suggestion correctly, he's proposing a hard-coded set
> of buttons in the/each toolbar, each of which will have its visibility or
> invisibility set by a CSS flag.

Not necessarily in CSS, although that's one possibility.  They're not
necessarily hardcoded, they could be moved between toolbars, and even into
menus.  That's bug #17306 - and to my knowledge that could not be done with CSS.

Ideally, it would be as you suggest, with a bunch of defined buttons and the
stylesheet defining the order and what appears.  However, XUL and CSS leave a
lot to be desired IMHO.  CSS doesn't allow you to take a list, extract certain
elements and/or place them in certain orders.  Maybe XSL does.  And XUL is a
kind of strange language, which consists of "content", which is mainly in JS
anyway, and "style", ie the order in which things appear.  Ideally you would
have a list of actions and data and an advanced stylesheet that renders them
into an interface.  But, as we're stuck with what we've got, the XUL becomes a
default arrangement of actions and data.  Stuff can be removed, and moved.

> (a) Mozilla would be wasting time and memory by loading data about buttons
> which weren't ever being used

Whether it loads button data it doesn't need to is implementation-dependant, it
need not.  It might create new XUL out the front.

Either way, the fact remains this is necessary.  When someone designs an XUL
skin they are providing a set of facilities.  It is impossible to tailor to
every single person, and different people will want different buttons.  Hence
each skin needs to be customised, without users being able to ruin a skin.

> (b) it wouldn't make adding custom-function buttons any easier
> because you'd still need to add them to the XUL by some other method.

No, it wouldn't, and it is not within the scope of this bug.  An XUL editor
would be a different facility, which would provide the default arrangement of
the skin and define the facilities.

> What would perhaps be better would be a single registry of buttons.
> Then all these buttons could be shown, on demand, in a Customize
> window (like the one in MS Office), and the buttons could be dragged
> to/from toolbars *or* menus.

Yes, I think it would be good to have a standard set of buttons, which could be
added to a skin.  This might be a standard overlay or something.  But this would
make this all the more important!
(Reporter)

Updated

20 years ago
Blocks: 18054
(Reporter)

Updated

20 years ago
No longer blocks: 17306

Comment 12

20 years ago
spam: changing qa contact from ckritzer -> paulmac for xul bugs

Comment 13

20 years ago
Appologies if this has already been thorougly covered/implemented. I am a
newbie. I would like to see it possible to reduce the toolbar height to no more
than a few pixels more than the address field. As such, I would like to see the
toolbar able to shrink in height when smaller or no buttons are chosen.

Also,
could someone please firect me to the apporpriate forum for discussing
keyboard
controls?

Thanks,
Gregory

Comment 14

20 years ago
heyboard controls can be discussed in the xpfe newsgroup

Updated

19 years ago
Status: NEW → ASSIGNED

Comment 15

19 years ago
BULK MOVE: Changing component from XUL to XP Toolkit/Widgets: XUL.  XUL 
component will be deleted.
Component: XUL → XP Toolkit/Widgets: XUL

Updated

19 years ago
Blocks: 29205

Comment 16

19 years ago
*IGNORE* - massive spam changing open XPToolkit bug's QA contact to
jrgm@netscape.com
QA Contact: paulmac → jrgm

Comment 17

19 years ago
Mass moving M18 bugs to M19
Target Milestone: M18 → M19

Comment 18

19 years ago
mass-moving all bugs to m21 that are not dogfood+ or nsbeta2+ or nsbeta2-
Target Milestone: M19 → M21
(Reporter)

Updated

19 years ago
Keywords: softui
(Reporter)

Updated

19 years ago
No longer blocks: 18054

Comment 19

19 years ago
->future
Target Milestone: M21 → Future

Comment 20

19 years ago
This is fixed with Hyatt'ss button prefs list checkin.  Waiting for hyatt to
resolve bug to verify.

Comment 21

19 years ago
This is fixed with Hyatt'ss button prefs list checkin.  Waiting for hyatt to
resolve bug to verify.

Comment 22

19 years ago
I don't want to close this.  This is referring to a full-blown toolbar 
add/remove capability (not the hack I did for navigator only in 6.0).

Updated

18 years ago
Depends on: 49543

Updated

18 years ago
Blocks: 71138

Updated

18 years ago
Blocks: 78532

Updated

18 years ago
Blocks: 84718

Updated

18 years ago
Blocks: 89005

Updated

18 years ago
Summary: Ability to add/remove toolbar buttons → Ability to add/remove toolbar buttons (customize toolbars)

Updated

18 years ago
Blocks: 104125
Adding self to Cc list.  

It is amazing how many minor RFEs are in the bug database
that would be automagically resolved if this were fixed.

Comment 24

17 years ago
Please, please, please make it so that you can customise the toolbar in the 
same way you can in IE6 etc. i.e. you can choose exactly what buttons you want, 
how big they are, whether they have text by them, how they're positioned etc. 
My IE browser is setup so everything is on one line incluidng "File, Edit 
etc..", the back/foward etc. buttons, addresss bar and Google search bar. I 
hate wasted space.

I don't care for stupid skins and **** like that. It's pointless.

While I'm ranting, I'm told that "Mozilla is an open-source web browser" so 
keep it that, just a web browser. I don't want mail, address book, wallet and 
other rubbish like that that'll just slow down the program and bloat it up 
worse than any of Microsoft's software. KISS - Keep It Simple Stupid.

Comment 25

17 years ago
This is disgusting, if you like the I.E. user interface, go and get it!!! use
Internet Explorer. But dont prentend to Mozilla be a clon of I.E.!

please read this bug.

http://bugzilla.mozilla.org/show_bug.cgi?id=129922

Comment 26

17 years ago
*** Bug 130798 has been marked as a duplicate of this bug. ***

Comment 27

17 years ago
adding self to cc list

Comment 28

17 years ago
I couldent agree more

Comment 29

17 years ago
Mass removing self from CC list.

Comment 30

17 years ago
Now I feel sumb because I have to add back. Sorry for the spam.
This bug is about ability to add/remove buttons to the toolbar without modifying
the actual skin. This is a _very_ important feature for many users. My
suggestion is that you/we implement this as soon as possible. For me, this would
be one of the top priorities, since it makes Mozilla more appealing to the user.

Comment 32

17 years ago
One of the good things about xul in the beggining was said it was going to be
very customizable once it was going to be made by a simple (at that time) language.
I do use KDE3 most of the time, and one of the features I most like is the
hability to edit toolbars buttons and choose postion, etc.
But this is minor compared to some things mozilla lost in the way of xul.
For example: I liked a lot the option to choose between buttons only or buttons
with text in the toolbar.
The only way to do this now is to build 2 skins almost identical.
I don't think it's a nice way of doing things...

Anyway, I think xul grown to bad and now it's like a demon that scaped the
control, most like windows, you can't fix it anymore, or you can?

Comment 33

17 years ago
*** Bug 94552 has been marked as a duplicate of this bug. ***
I put together a simple UI for a customization dialog. You can try it here:
http://xulplanet.com/ndeakin/tbcust.html
Neil, this is the customization UI mpt sent me via IRC a little while ago:

+---------------------------------------------------------------------+
|::::::::::::::::::::::::: Customize Toolbar :::::::::::::::::::::::::|
+---------------------------------------------------------------------+
| +-----------------------------------------------------------------+ |
| |  <=     =>    (_)   /_\   :  LJ   ()H      /\       (;)   :  [] | |
| | Back Forward  Stop Reload : Home Search Bookmarks History : Mail| |
| +-----------------------------------------------------------------+ |
| +-----------------------------------------------------------------+ |
| To add items, drag them into this toolbar from the list below or    |
| from the Finder. To remove items, drag them out of the toolbar.     |
|                                                                     |
| Available items:                 Button style:                      |
| +---------------------------+-+  ( ) Icons                          |
| |  : divider                |A|  ( ) Text                           |
| | :: spring divider         |:|  (*) Icons and text                 |
| | /+ Add                    |:|                                     |
| | /\ Bookmarks              |:|  Icon size:                         |
| | }{ Chat                   |:|  (*) Small                          |
| | [/ Edit                   |:|  ( ) Large                          |
| | @. Find                   |:|                                     |
| | () History                |V|  [/] Go button in Address Bar       |
| +---------------------------+-+                                     |
|                                               ( Cancel ) ((  OK  )) /
+--------------------------------------------------------------------/+

While I don't understand several things such as the "spring divider" (maybe
that's a spacer with flex?) yet, it appears to be a nice dialog.

Comment 36

17 years ago
Why do we have bug 116183?  Shouldn't that one be marked a dupe of this one?

Updated

17 years ago
Blocks: 157199

Comment 37

17 years ago
I knocked up a quick demo of an RDF+templates solution for the toolbar as
suggested by Ben in comment 2. It overlays a toolbar with Back, Forward, Reload
and Stop, but with all the information taken from an RDF file.

Two things are broken:
1. "observes" doesn't work. Could this be an internal XUL thing, in that the
attributes are created too late? (guessing)
2. The images on the toolbar buttons are very wrong, because the images are
determined by the id of the toolbarbuttons, and the template mechanism (I think)
overrides the id with its own value.

Comment 38

17 years ago
Matthew:
Can't we set the id with the template mechanism? (using id="?buttonid" or
something similar)
Addinitionally, I think we should make the urlbar an XBL element, so that we can
simply flip it in the toolbar via that mechanism. We could even create all the
buttons as XBL elements and just set some CSS class or something similar that
references the XBL element and creates the binding. That way the RDF can be
quite simple, and culd easily extend the model to additionally set a "textonly"
or "icononly" CSS class as well, so that theme CSS can deal with that quite
well, I think.

Comment 39

17 years ago
>Can't we set the id with the template mechanism? (using id="?buttonid" or
> something similar)

Doesn't seem to work for ids, the element gets given an id based on the 'about'
attribute in the RDF.

Comment 40

17 years ago
I'm making a XUL application. I know this is not a solution,
but this might be a workaround, including many related bugs (I hope).

"Custom Menubar"
http://member.nifty.ne.jp/georgei/mozilla/custom_menubar_en.html

Please note that it is under development.

Comment 41

17 years ago
*** Bug 116183 has been marked as a duplicate of this bug. ***

Updated

17 years ago
Blocks: 155562

Updated

17 years ago
No longer blocks: 29205

Updated

17 years ago
Blocks: 156916

Updated

17 years ago
No longer blocks: 156916

Updated

17 years ago
Blocks: 156916

Comment 42

17 years ago
Adding my self to the CC
Just take another look at how many bugs would be resolved if this was fixed.

Comment 43

17 years ago
Please make it possible to tab to the items you want and hit Enter, or select
them / check them from the list. Click and drag is not accessible, it will be
harder to retrofit that than design it in.

Comment 44

17 years ago
What with the Tab bar buttons?

I filed a bug days ago about them ( Bug 161857 ), but it was resolved WONFIX
because of this.

Are they going to be part of the "Customize Toolbar" Window, that Sören
"Chucker" Kuklau has drawn in Comment 35?

Comment 45

17 years ago
Maybe they could be added to the check box list, under of the "Go button in
Address Bar" item.

+---------------------------------------------------------------------+
|::::::::::::::::::::::::: Customize Toolbar :::::::::::::::::::::::::|
+---------------------------------------------------------------------+
| +-----------------------------------------------------------------+ |
| |  <=     =>    (_)   /_\   :  LJ   ()H      /\       (;)   :  [] | |
| | Back Forward  Stop Reload : Home Search Bookmarks History : Mail| |
| +-----------------------------------------------------------------+ |
| +-----------------------------------------------------------------+ |
| To add items, drag them into this toolbar from the list below or    |
| from the Finder. To remove items, drag them out of the toolbar.     |
|                                                                     |
| Available items:                 Button style:                      |
| +-------------------------+-+  ( ) Icons                            |
| |  : divider              |A|  ( ) Text                             |
| | :: spring divider       |:|  (*) Icons and text                   |
| | /+ Add                  |:|                                       |
| | /\ Bookmarks            |:|  Icon size:                           |
| | }{ Chat                 |:|  (*) Small                            |
| | [/ Edit                 |:|  ( ) Large                            |
| | @. Find                 |:|                                       |
| | () History              |:|  [/] Go button in Address Bar         |
| |                         |:|  [/] Open a new tab button in Tab Bar |
| |                         |V|  [/] Close tab button in Tab Bar      |
| +-------------------------+-+                                       |
|                                               ( Cancel ) ((  OK  )) /
+--------------------------------------------------------------------/+

Updated

17 years ago
Blocks: 163993
So, why has no-one tried back-porting the code from Phoenix into the Mozilla
trunk? It would probably be quite easy to do.
Since this hasn't been worked on and has been around since 1999, can a 
seasoned developer that doesn't have a lot of time please provide a synopsis 
of what needs to be done for a non-seasoned developer who might want to bring 
this to fruition (not me) and also possibly create blocking bugs if there are 
underlying issues that need to be resolved? Or if it is being worked on, is 
there a status update available?

*See also bug 17306*
All that needs doing is someone needs to look at how it works in
/mozillo/browser and port that code to the /mozilla/xpfe codebase. Shouldn't be
very hard.
Just a small note for comment 35 and comment 45: The Ok and Cancel buttons
should switch place. :)
Re: Comment #49 From David Tenser 2002-09-16 06:54
> Just a small note for comment 35 and comment 45: The Ok and Cancel buttons
> should switch place. :)

Maybe on Win32, GTK, etc., but not on Mac OS [X].
Would it be posible to be able to put any menu item in any toolbar?
For example, I want to edit the Navigator toolbar and the toolbar in
the window that display an email.

Comment 52

16 years ago
I would like to be able to move the position of buttons on the toolbar. Such as
putting the "Print" button next to the "Stop" button.

Comment 53

16 years ago
That's bug 17306.
->jag, but reassign as needed.
Assignee: hyatt → jaggernaut
Status: ASSIGNED → NEW

Comment 56

16 years ago
Adding myself to the list...Additionally, being able to add/remove buttons to
the navigation bar and being able to move the address bar into the menu bar
would be nice.

Comment 57

16 years ago
*** Bug 203763 has been marked as a duplicate of this bug. ***

Comment 58

15 years ago
have you guys used Allaire Homesite?  To me, that represents the ultimately
customizable menu/folder system--you can cusomize every set of folders/menus,
and then dock or undock them anywhere at will.  I would love to see something
like this for Firefox--but maybe it would be more appropriate as an extension?

Comment 59

15 years ago
matt: This is in Browser product, which here means SeaMonkey browser. If you
want a change in FirFox' toolbars, that's a completely different thing, as it's
using a new toolkit that's not in Seamonkey, so your comment doesn't apply here.
*** Bug 244228 has been marked as a duplicate of this bug. ***

Comment 61

14 years ago
*** Bug 279459 has been marked as a duplicate of this bug. ***

Updated

14 years ago
No longer blocks: 163993

Comment 62

14 years ago
This is becoming more important for many of us using SeaMonkey as extensions gravitate toward the FF UI capabilities. One example is SpoofStick, which will install in SM without a problem, but the latest builds consist of a customizable toolbar button...the problem, of course, is how to (easily) add a customizable toolbar button to one of SeaMonkey's toolbars.
> the problem, of course, is how to (easily) add a customizable toolbar button
> to one of SeaMonkey's toolbars.

Once bug 282188 is fixed, we should be able to come to solution here rather quickly -> adding dependency.
Depends on: 282188

Comment 64

12 years ago
Is this bug a seamonkey-only bug? Is it about increased flexibility of the customize toolbars mechanism? Is it about 'XUL editors' available by default to dynamically customize the chrome? I'm confused...

Comment 65

12 years ago
Eyal:
This is SeaMonkey-only, and nowadays it's about SeaMonkey gaining the same or very similar functionality to what Firefox and Thunderbird already have in that area, i.e. the possibility for users to customize the position of their toolbar items and which of them are shown at all.

Updated

11 years ago
Component: XP Toolkit/Widgets: XUL → XUL
QA Contact: jrgmorrison → xptoolkit.widgets
Assignee: jag → nobody

Comment 66

10 years ago
Moving all dependencies to Bug 157199.

Also marking fixed since trunk is fully tookitized we have access to the toolkit customize toolbar functionality, and this is currently being used in the Navigator window.
Status: NEW → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → FIXED

Updated

10 years ago
Blocks: 157199

Updated

9 years ago
Duplicate of this bug: 94552
You need to log in before you can comment on or make changes to this bug.