Closed Bug 15144 Opened 25 years ago Closed 15 years ago

Ability to add/remove toolbar buttons (customize toolbars)

Categories

(Core :: XUL, enhancement, P5)

Product:
Core
Component:
XUL
Type:
enhancement

Tracking

()

Status:
RESOLVED FIXED
Milestone:
Future

People

(Reporter: CodeMachine, Unassigned)

References

(Blocks 1 open bug)

Details

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.
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)
Assignee: trudelle → hyatt
Priority: P3 → P5
Target Milestone: M14
reassigning to hyatt for consideration post-beta
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.
Summary: Toolbar button repository. → Ability to remove toolbar buttons
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.
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 :)
Target Milestone: M14 → M18
Summary: Ability to remove toolbar buttons → Ability to add/remove toolbar buttons
Adding myself to the CC: list if you don't mind 8-)
Something you would also want is the capability of having buttons that are
initially removed.
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).
> 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!
Blocks: 18054
No longer blocks: 17306
spam: changing qa contact from ckritzer -> paulmac for xul bugs
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
heyboard controls can be discussed in the xpfe newsgroup
Status: NEW → ASSIGNED
BULK MOVE: Changing component from XUL to XP Toolkit/Widgets: XUL.  XUL 
component will be deleted.
Component: XUL → XP Toolkit/Widgets: XUL
Blocks: 29205
*IGNORE* - massive spam changing open XPToolkit bug's QA contact to
jrgm@netscape.com
QA Contact: paulmac → jrgm
Mass moving M18 bugs to M19
Target Milestone: M18 → M19
mass-moving all bugs to m21 that are not dogfood+ or nsbeta2+ or nsbeta2-
Target Milestone: M19 → M21
Keywords: softui
No longer blocks: 18054
->future
Target Milestone: M21 → Future
This is fixed with Hyatt'ss button prefs list checkin.  Waiting for hyatt to
resolve bug to verify.
This is fixed with Hyatt'ss button prefs list checkin.  Waiting for hyatt to
resolve bug to verify.
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).
Depends on: 49543
Blocks: 89005
Summary: Ability to add/remove toolbar buttons → Ability to add/remove toolbar buttons (customize toolbars)
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.


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.
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
*** Bug 130798 has been marked as a duplicate of this bug. ***
adding self to cc list
I couldent agree more
Mass removing self from CC list.
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.
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?
*** 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.
Why do we have bug 116183?  Shouldn't that one be marked a dupe of this one?
Blocks: 157199
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.
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.
>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.
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.
*** Bug 116183 has been marked as a duplicate of this bug. ***
No longer blocks: 29205
Blocks: 156916
No longer blocks: 156916
Blocks: 156916
Adding my self to the CC
Just take another look at how many bugs would be resolved if this was fixed.
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.
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?
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  )) /
+--------------------------------------------------------------------/+
Blocks: majorbugs
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.
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.
That's bug 17306.
->jag, but reassign as needed.
Assignee: hyatt → jaggernaut
Status: ASSIGNED → NEW
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.
*** Bug 203763 has been marked as a duplicate of this bug. ***
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?
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. ***
*** Bug 279459 has been marked as a duplicate of this bug. ***
No longer blocks: majorbugs
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
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...
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.
Blocks: 49543
No longer depends on: 49543
Blocks: 170994
Component: XP Toolkit/Widgets: XUL → XUL
QA Contact: jrgmorrison → xptoolkit.widgets
Assignee: jag → nobody
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.
No longer blocks: 49543, 71138, 78532, 84718, 89005, 104125, 155562, 156916, 157199, 170994
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Blocks: 157199
You need to log in before you can comment on or make changes to this bug.