Closed Bug 17306 Opened 25 years ago Closed 5 years ago

[feature] Ability to move around menu items/toolbar buttons.

Categories

(Core :: XUL, enhancement, P4)

Product:
Core
Component:
XUL
Type:
enhancement

Tracking

()

Status:
RESOLVED WONTFIX
Milestone:
Future

People

(Reporter: CodeMachine, Unassigned)

References

Details

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.
Assignee: trudelle → hyatt
Target Milestone: M14
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.
Blocks: 18054
Depends on: 15144
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.
No longer depends on: 15144
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
Target Milestone: M14 → M15
targetting m15
Status: NEW → ASSIGNED
Target Milestone: M15 → M16
BULK MOVE: Changing component from XUL to XP Toolkit/Widgets: XUL.  XUL 
component will be deleted.
Component: XUL → XP Toolkit/Widgets: XUL
*IGNORE* - more massive spam, changing open XPToolkit bug's QA contact to
jrgm@netscape.com
QA Contact: paulmac → jrgm
*IGNORE* - massive spam changing open XPToolkit bug's QA contact to
jrgm@netscape.com
Summary: Ability to move around menu items/toolbar buttons. → [feature] Ability to move around menu items/toolbar buttons.
Target Milestone: M16 → M18
No time left in this release, resolving as later, putting on helpwanted radar
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → LATER
darn it, I'll take this one and untarget it
Status: RESOLVED → REOPENED
Resolution: LATER → ---
.
Assignee: hyatt → ben
Status: REOPENED → NEW
untargeting. will do something like this if I ever get some spare time ;)
Status: NEW → ASSIGNED
Target Milestone: M18
not a priority, pushing out as far as possible.
Target Milestone: --- → M20
Move to "Future" milestone.
Target Milestone: M20 → Future
Keywords: softui
No longer blocks: 18054
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
Blocks: 153645
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*
No longer blocks: 153645
Component: XP Toolkit/Widgets: XUL → XUL
QA Contact: jrgmorrison → xptoolkit.widgets
Assignee: bugs → nobody
Status: ASSIGNED → RESOLVED
Closed: 24 years ago → 5 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.