It would be good to be able to move around menu items in their menus, toolbar buttons in their toolbar, menu items between menus, toolbar items between toolbars, rearrange menus, move menu items to toolbars, and toolbar items to menus, all without changing the underlying XUL/CSS. There are a couple of issues with this. Firstly, since any menu item can become a toolbar button and vice versa, attributes which are currently on menus only should also be able to be placed on toolbar buttons, and vice versa, since one can become the other, and hence these attributes could be useful later in a non-default configuration. Secondly, this suggests removing the distinction between the menu item and toolbar button tags, since they would have the same attributes. Thirdly, what would you do about duplicate access keys? A couple of possibilities are to place a higher priority to the original keys (but what about between two dropped keys - the first dropped gets priority?), or a more simple scheme of making the higher item win out. Fourthly, there should be some notion of "compound items" that can't be split up. These include radio groups which all must be together (either within menus or a toolbar), and computed data such as bookmarks, or (once you can add toolbars) the list of toolbars that exist.

2) Please do not create just one element. It is important to maintain two different elements since they ARE distinct elements, at least in a conceptual sense. 3) access keys would work just as you say, if something on the bar already has the accesskey assigned, then it "wins" and the dropped item loses it. Using that as a governing rule, working out what happens to successive drops is simple. 4) I find it hard to imagine why you'd want to drag a checkbox or radiogroup menuitem set to a toolbar. I'm not sure what kind of UI will be offered for all this customisation, as D&D isn't even working yet. What might be easier (from an implementation point of view) is a dialog. That would even work on Mac (as representations of menu items could easily be displayed in the dialog). Note that this notion of drag and drop menu items does not work on Macintosh (at least not in the sense that it might with XPMenus). With a dialog it'd be easier (I would imagine) to tackle these issues.

> Please do not create just one element. It is important to maintain > two different elements since they ARE distinct elements, at least > in a conceptual sense. My point is that they are conceptually the same, and they are only technically different. They are both actions. They only seem different because that's what we've been used to. Why can't you create some sort of action fragment, and have the place where it's used determine how it operates? > 4) I find it hard to imagine why you'd want to drag a checkbox or > radiogroup menuitem set to a toolbar. See the left/right/centre/justified tool buttons on your favourite word processor. > I'm not sure what kind of UI will be offered for all this customisation, > as D&D isn't even working yet. Irrelevant, since it will be by the time this occurs. > What might be easier (from an implementation point of view) is a dialog. > That would even work on Mac (as representations of menu items could easily > be displayed in the dialog). Note that this notion of drag and drop menu > items does not work on Macintosh (at least not in the sense that it might > with XPMenus). With a dialog it'd be easier (I would imagine) to tackle > these issues. This is certainly an issue, and I haven't really discuss how this should be done. Doing this inline is easier for a power user, but it shouldn't be something you can do accidentally (like moving items around the start menu in Windows 98). Hence I think right click and right drag and feasible ways of doing this. The die is already cast - we have things like View Sidebar and View Toolbar. Why not everything else? There are certainly issues with the Mac, right mouse click and lack of xpmenus. I think that the Mac has conventions for contextual menus, etc. Inline editing might also be more difficult for a newbie to find the facilities. Hence, both would be nice.

> See the left/right/centre/justified tool buttons on your favourite word > processor. --- hrm, point taken. I'm not sure how this sort of group of titledbuttons is handled at the moment, I think its just done through JS. It might be more elegant to create groups as you suggest. I still don't see people dragging them around, though :) > There are certainly issues with the Mac, right mouse click and lack of > xpmenus. I think that the Mac has conventions for contextual menus, etc. > Inline editing might also be more difficult for a newbie to find the > facilities. --- "Newbies" (I assume you mean grandma) won't use this, trust me, at least, not without someone there telling them what to do. (For grandma, a dialog is probably BETTER because the dialog approach prevents them from accidentally dragging their toolbar contents all over the place.) Providing a nicely designed dialog, with internal drag-drop, customisation needn't be a chore. I do like the easy editing and manipulation of buttons in Classic however, which does contradict the dialog idea somewhat.

On second thoughts, I don't think that inline editing is really necessary. Changing your setup is a quite rare situation. I don't know whether "dialog" is the right word, but certainly another window, set up well, could do this well and simply. Hence, the specific actions that do allow it to be done inline, should be chosen on the basis of how often you might want to change them. The "view sidebar" makes sense - the toolbars possibly don't, and the ability to remove toolbars through a skin modifier window might well allow them to be removed, although it does raise the issue of whether soft UI changes should be able to be this-session-only.

> 3) access keys would work just as you say, if something on the bar > already has the accesskey assigned, then it "wins" and the dropped > item loses it. Using that as a governing rule, working out what > happens to successive drops is simple. By "access key", are you referring to the mnemonic or underlined menu accelerator? If so, the default behavior in Windows for duplicate keys is that neither menu item "wins". Pressing the access key will cycle through all of the menu items that have it defined. For an example in Windows, look at the View > Character Set menu in Communicator 4.x. I can use the 'C' key to cycle through six different selections.

In bug 15144 I propose a way of implementing this -- a single repository of menu/ toolbar widgets, which can be dragged to or from menus, toolbars, and a Customize window. Note that such a widget record would need to have both a short and a long caption; the short one to appear on a toolbar button in show-toolbar-buttons-as- -pictures-and-text mode, and the long one to appear when the item is in a menu.

This is a possible implementation, but that does not dictate the dependency you set, because: 1. These bugs are totally independent, any implementation of what you suggest is of both, and dependencies are non-symmetric. If you wanted a dependence relationship both should depend on a third bug. 2. No implementation has yet been acted upon (unless you're writing or planning to write it), and hence it is inappropriate to depend based on a possible implementation. Hence I am unsetting it.

Mea culpa.

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

targetting m15

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

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

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

No time left in this release, resolving as later, putting on helpwanted radar

darn it, I'll take this one and untarget it

.

untargeting. will do something like this if I ever get some spare time ;)

not a priority, pushing out as far as possible.

Move to "Future" milestone.

Actually, I vote for customization of toolbars, but against customization of menus. If you allow customization of menus, then help files, tech support, etc become impossible, because you can't rely on users having a given menu item in a given menu. (And saying `well, if they customized it, they shouldn't expect to be able to get help/support' is not valid, as long as there are still insecure single-user OSes, as long as humans treat multi-user OSes as single-user OSes, and as long as humans make mistakes.) If customization of menus was allowed, you could even accidentally customize the `Customize ...' menu item out of existence, for example -- and then you'd be well and truly stuck.

A note to the interested: work on the infrastructure to support this is beginning. I have started working on massaging XUL overlays to support deep merging of content in nested subtrees, and XUL persistence to make it use overlays written into the user's profile directory rather than the localstore. With these fundamentals in place, configurable toolbars should be a matter of designing and implementing a UI. The nsXULDocument work is fairly hairy though (at least for a rookie in this area like myself), and I can see it taking up my time for a while. This would be a neat feature for 6.5/1.0 however.

<quoting mpt> Actually, I vote for customization of toolbars, but against customization of menus. If you allow customization of menus, then help files, tech support, etc become impossible, because you can't rely on users having a given menu item in a given menu. </quoting mpt> I think this wasn´t meant to allow users to reconfigure their "Edit", "Search" and whatever standard menus. I understood it as being able to do things as follows (directly taken from bug #59608 , I´ll mark it duplicated then): <bug-59608> 1) similar to the personal toolbar, a personal taskbar would contain "actions" like "View->Headers->all","Task->Chatzilla","Edit->Preferences","Message- >Forward As->inline" and many, many more you can think of... Then every regularly used action can be accessed with ONE click without the need to perform over and over the same annoying procedures (eg. me, I use View- >Headers->All|normal a lot to verify origin etc.) It would be an enormous enhancement over the current situation where only "Search","Go","Print" and such are configurable in the Prefs. I can build an unlimited amount of scenarios where this could be practicable. 2) A further enhancement over this would be to allow not only singular actions, rather than allowing TOGGLES. eg. In my case it would be fine to have two entries in this personal taskbar "All Headers" - "Normal Headers" compared to the current situation. But it would be a lot better to be able to toggle/switch through a bunch of options in a whole menu. In my case "Switch Headers" what switches between the two available options View->Headers->All, View- >Headers->Normal another switch could be "Message->Forward As" to switch between inline/attachement another could be "Character Coding" and so on, depending on user behaviour they can customzie mozilla more flexible and easy than possible with ANY other browser I know of... </bug-59608> Hope not to have spammed this bug, but I´m not sure if all parties think about the same issue (me included).

*** Bug 59608 has been marked as a duplicate of this bug. ***

*** Bug 122332 has been marked as a duplicate of this bug. ***

adding self to cc list

I assume this refers to all kinds of menus. 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 15144*