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)

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.

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 :)

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!

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

BULK MOVE: Changing component from XUL to XP Toolkit/Widgets: XUL. XUL component will be deleted.

*IGNORE* - massive spam changing open XPToolkit bug's QA contact to jrgm@netscape.com

Mass moving M18 bugs to M19

mass-moving all bugs to m21 that are not dogfood+ or nsbeta2+ or nsbeta2-

->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).

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?

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. ***

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 )) / +--------------------------------------------------------------------/+

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.

See specs: http://www.mozilla.org/projects/ui/

->jag, but reassign as needed.

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. ***

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.

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.

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.