Ability to rearrange toolbars (by drag and drop)

NEW
Unassigned

Status

enhancement
20 years ago
2 years ago

People

(Reporter: CodeMachine, Unassigned)

Tracking

(Depends on 1 bug, Blocks 2 bugs)

Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [cst: probably never happening], )

Attachments

(1 attachment, 6 obsolete attachments)

At the moment there's no way to reorder the toolbars vertically.  It would be
nice to.  I'm not sure how this should be done however, ie I'm of the opinion
that a skin's XUL and CSS should not be changed by this operation.  For example,
does the current feature of hiding toolbars edit the XUL?

Once this is done, I'll put in a nice RFE to put multiple toolbars on the same
line.
At the moment, the bottom toolbar is in a different toolbar than the top ones.
This should be changed so that you can drag the bottom toolbar to the top if you
want.

This might require allowing things other than toolbars to appear in a toolbox.
This should be doable, simply don't allow them to be dragged/collapsed in the
same way (although maybe you MIGHT want to allow this for anything for some
applications using the Mozilla architecture, especially the ability to float
bits of content (when implemented for toolbars)).
Target Milestone: M14
m14
Assignee: trudelle → hyatt
Target Milestone: M14 → M18
reassigning to hyatt for m18
It would be nice to be able to move a toolbar a horizontal toolbar to be
vertical as well.

Basically a toolbar should be able to move to any border of its bounding box.
Blocks: 18054
Status: NEW → ASSIGNED
Summary: Toolbar movement. → [feature] Toolbar movement.
No time left in this release, resolving as later, putting on helpwanted radar
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Keywords: helpwanted
Resolution: --- → LATER
reopening all latered bugs
Status: RESOLVED → REOPENED
Resolution: LATER → ---
Moving all latered bugs to M20 as ordered by project manager.  Although these 
bugs are now open, assigned and targetted, XPToolkit has no plans to 
fix/implement them in the current release cycle, if ever.
Target Milestone: M18 → M20
Mass move of all M20 bugs to M30.
Mass move of M20 bugs to M30
Target Milestone: M20 → M30
Please don't include the menubar like IE does.
Mass-moving all M20-M30 XPToolkit bugs to Future
Target Milestone: M30 → Future
Keywords: softui
No longer blocks: 18054
*** Bug 47584 has been marked as a duplicate of this bug. ***
Blocks: 48926
I propose putting this on the radar for mozilla1.0.1. There are other bugs
dependent on this, and it's been open for about 1.5 years now. What do you think?
Keywords: mozilla1.0
I put together a patch to enable vertical reordering of toolbars (within a
toolbox) by dragging the grippy handles.  This is my first patch so I'd
appreciate any advice!!  Diff was made using Gerv's patchmaker utility based off
win2k build 2001100610.  I had to hack the patchmaker script to get it to work
on my system, so hopefully it works.

The patch borrows a lot from the outliner column reordering.  It uses the
ordinal attribute to control display order so it doesn't mess with the content
model.  

There are several issues with the patch as-is, off the top of my head:

- XUL authors can't specify whether toolbars can or can't be reordered; it
currently applies to all toolbars. Probably should add an "enableToolbarDrag"
attribute or something similar on the <toolbox> to specify.
- Same as above for persisting the order; right now it's always persisted. 
- Doesn't distinguish between toolbars and menubars, both can be dragged
(good/bad is a matter of opinion).
- Dragging is confined to the <toolbox>. Anything more is a much larger scope.
- User feedback as to where the dragging toolbar will be inserted needs work.
It's specified on a per-skin basis. The current patch adds a black line for
feedback to classic and modern skins, but it sucks. Needs polish.
- Weird things may happen when adding new toolbars via overlays after reordering
existing toolbars. Same to a lesser extent with turning on toolbars that were
turned off or collapsed during reordering.
- Others, I'm sure.  Needs to be put through its paces, esp. with overlays.
Status: REOPENED → ASSIGNED
Target Milestone: Future → mozilla0.9.6
Fantastic, Jason!  I'll look at this tomorrow (Monday).
Jason: cool :-) I think, however, that there may be a problem with your patch,
possibly due to a bug in Patch Maker.

Could you please download and drop in the latest version, Patch Maker 0.4, and
re-create the patch (pmd)? Then, remember to attach the file that ends in .diff
(and not .chromediff.)

Gerv
There are a few lines that show up as changed when you didn't actually change
those lines.  Either you inserted extraneous spaces that should be removed, or
patch maker is doing it.  Not sure which.
Gerv and Dave-- I see what you mean about the patch.  I'll try using the new
version of Patchmaker when I get home tonight.  The patch I attached was the
.diff not the .chromediff, but looking at the two they're exactly the same to
the character.  So something with the chrome->cvs diff conversion isn't
happening right.  I'm thinking it might have something to do with perl treating
the backslashes in the chromelist as escape characters; I'll let you know what I
find out.

I think that the deal with unchanged lines showing up as changed has to do with
the "feature" of my text editor where it strips trailing whitespace off each
line when saved.  Handy when writing HTML, but I obviously need to turn it off
or use another editor for Mozilla hacking. ;-)

I'll attach a revised patch hopefully tonight.
Actually don't.  Stripping off trailing whitespace is a good thing. :)
Okay, I think I got it figured out.  Gerv, it was an issue with the
chromelist.txt using backslashes in the chrome paths, which perl was treating as
escape characters.  Changing them all to foreslashes, as in the unix version,
made it play nice.  (I'm running Win2K; it doesn't have a problem with
foreslashes for paths, but other Win32 versions may.)

My next version of the patch, besides hopefully being a valid patch ;-), has
some changes for performance and neatness, as well as an attempt to fix the
problems with un-hiding toolbars or overlaying new toolbars.  It sets the
ordinals to negative integer values when reordering, so theoretically a newly
added toolbar should display at the bottom since its initial value should be 1
(per the spec).  However, this doesn't appear to be working (new toolbars show
at the top.)  Dave, is this perhaps a bug with the ordinal implementation, or am
I interpreting it wrong?
Posted patch patch version 3 (obsolete) — Splinter Review
Above patch (version 3) eliminates the stupid black line; it just goes ahead and
moves the toolbar.  This is much simpler and brings it much closer to the
Communicator 4.x behavior.
Does the scope of this bug cover being able to move toolbars to bottom of the
window, where the Components Bar and Status Bar are?
Unfortunately enabling toolbars to be moved to the bottom of the window would
require a rethink of the whole toolbox/toolbar system.  While I'm not opposed to
that, I think we should make small steps to 4xp first, and then consider larger
changes post-1.0.  Maybe you should file another bug for allowing toolbars be
moved outside their toolbox.
Adding a toggle to move the toolbar to the bottom of the window would require
approximately 8 seconds of work.
It took asa 8 seconds.  I can do it in 4.
Oh, my bad, I see you already have a patch with box ordinal so you're obviously
aware of it (I thought you were plairoesque)...so why would it be so difficult?
 Asa did it in his userchrome with one line.  Maybe I'm missing what's being
asked for?
I thought that Tim was asking for single toolbars (e.g. the personal toolbar
ONLY) to be moved to the bottom of the window; I think what Asa did was to move
the whole *toolbox* to the bottom.  If I'm mistaken please let me know how it
was done so I can incorporate it into my patch.  Thanks.

Plairoesque... heh. ;-)
*** Bug 104324 has been marked as a duplicate of this bug. ***
Posted patch patch, version 4 (obsolete) — Splinter Review
Version 4 of the patch is finally what I'd call review-ready. I'll address each
of the issues I brought up on Oct.6:

- XUL authors can now specify the attribute: preventToolbarDrag="true" on the
<toolbox/> element to prevent the user from rearranging its bars. This seemed
much better than having to specifically allow dragging on each and every toolbox.
- I left it so that the order is always persisted after a drag. It seemed to me
that it's sort of an "all-or-nothing" on persistence, and would be a pain for
XUL authors to have to add persist="ordinal" to all their toolbars.
- Toolbars and Menubars can both be dragged; if you don't want to change the
position of your menubar, then ... don't.
- Dragging is still confined to the toolbox. I still think the toolbox/toolbar
scheme will have to be rethought in order to allow anything more.
- Toolbars are rearranged while dragging, so no user feedback issues.
- I changed the default -moz-box-ordinal-group for toolbars to -1 in xul.css (if
there's a better place for this let me know.) so that newly added toolbars will
display at the bottom. This doesn't apply for menubars so they'll display at the
top.
- There still may be bugs but I didn't find any when adding 3 overlayed toolbars
to the default 4 in navigator.

So I guess this is ready for review when y'all get a chance.
Target Milestone: mozilla0.9.6 → mozilla0.9.7
Can you get me a patch that is current with the tip?  I'll take a look at that
and supply comments.
Thanks Dave- I'll be out of town until Monday; I'll attach a current patch when
I get back next week.

I also need to have it tested on Macintosh, since I remembered the <menubar/> is
kept on the top of the screen on the Mac and I don't know how that would behave
with box-ordinal.
I found a few minutes to update the patch to the tip.  This is exactly the same
code as before; there were no merge problems.  I look forward to your input.
Attachment #52415 - Attachment is obsolete: true
Attachment #52658 - Attachment is obsolete: true
Attachment #52981 - Attachment is obsolete: true
Attachment #53453 - Attachment is obsolete: true
Target Milestone: mozilla0.9.7 → mozilla0.9.8
I tested this in Win2k with build 2001120303 (I get lots of javascript errors,
not related to this bug - I believe)

I found one or two little problems with the operation of this patch though.

- There is no visual feedback. How about changing the mouse cursor when dragging?
- When I move the cursor outside of the window, it stops dragging.  Was this
intentionally done? (Couldn't find the spot in the code which handles this) With
no visual feedback it's hard to know if I'm still dragging or not.
- In the message compose dialog, you have to drag some of the toolbars, what
seems like, a large distance before they'll move.

Works fine with the translate bar (you can't move the bar up) and the site
navigation bar on autohide.  It also appears to work in all other windows which
have toolbars at the top.

When the toolbars were collapsed, I couldn't seem to re-arrange them.  That's
probably a good thing :)

As for the code, it looks good, but I'm not one to make suggestions on that. 
The patch seems solid though.
Thanks for your comments, Neil.  Any JS errors that have to do with this patch
would show toolbar.xml as their source -- any other source is most likely unrelated.

> - There is no visual feedback. How about changing the mouse cursor when 
> dragging?

I agree that some sort of user feedback would help.  What's the etiquette for
changing the cursor; can I do that directly with a .style.cursor in the JS, or
do I need to set an attribute somewhere and let the skin CSS determine how the
feedback is displayed?

> - When I move the cursor outside of the window, it stops dragging.  Was this
> intentionally done? (Couldn't find the spot in the code which handles this) 
> With no visual feedback it's hard to know if I'm still dragging or not.

This was intentionally done as a workaround for not being able to detect mouse
events outside the window.  I couldn't detect when the user dragged outside the
window and let up the mouse button, so when the mouse came back into the window
the toolbar would still be dragging and you'd have to click in the toolbox to
cancel it.  I agree this is a less-than-elegant workaround, so if anyone has a
better idea I'm all ears.

Actually dragging is canceled whenever the cursor enters a region of the window
that is not within the originating <toolbox/>.  The code to detect this is in
the toolbox.dragMouseMoved method.  BTW, this is the exact same behavior as in
Communicator 4.x.

Implementing visual feedback (cursor, etc.) will help out with this, so the user
will see when his drag has been canceled.

> - In the message compose dialog, you have to drag some of the toolbars, what
> seems like, a large distance before they'll move.

The toolbar will snap to the closer side of whichever toolbar the mouse is
currently over.  So the mouse has to move past halfway down the height of the
toolbar to make the toolbar snap to the lower position.  This can make it seem
very resistant over huuuuuge toolbars like in message compose, but it's the only
way I can think of that makes sense.  Suggestions welcome as always.

=======

So, to summarize:
1) Is it polite to set .style.cursor="move" directly in the JS?
2) Is there a way to detect mouseup events outside the window boundaries?  I
found window.enableExternalCapture() in lxr but it appears to not be implemented.
> This can make it seem very resistant over huuuuuge toolbars like in message 
> compose, but it's the only way I can think of that makes sense.  Suggestions 
> welcome as always.

Well, an alternate way would be to grab the X, Y of the mouse, then when it 
moves, you figure out if it has been moved up or down.  Then you check to see if 
it has moved outside a tolerance.  That way, it wouldn't matter how big the 
toolbar was.  Of course you might run into problems if the mouse hits the top of 
the screen and stops.

eg, the tolerance is 5px.  So they click, and move the mouse up 5px.  The 
toolbar moves up one slot.  They move 10px, and it moves up 2 slots.

It might also run into problems later on if you allow multiple toolbars on one 
line, or docking on the side and stuff.

Anyways, it's just a suggestion.  I don't have a preference either way.
Is this going to have to be retooled when we get to 48926, or is it extensible?
Dean-- this is code based on the current toolbar/toolbox relationship.  The
current design is very basic and inflexible, therefore so is the code to
manipulate it.  Bug 48926 would basically be a (well-needed) complete rebuild of
the toolbar widgets, and so I doubt the code in this patch would work in that
new system.  But that rebuild seems a long way off (futured), and this is a
relatively simple patch that could give us some nice added functionality in the
short-term.

Speaking of 48926, I really don't think this bug blocks that one.  Anyone agree?
*** Bug 114830 has been marked as a duplicate of this bug. ***
Target Milestone: mozilla0.9.8 → mozilla0.9.9
I just noticed attachment 65067 [details], a complete spec for the toolbar system
redesign, submitted by MPT in bug 49543.  It's quite apparent that the work I've
done for this bug will not fit in that new system whatsoever, so I hereby
withdraw my patch in favor of moving ahead toward the toolbar rewrite.  

Thanks everyone for your input.  It's been a great learning experience and I
hope to be able to contribute to the rewrite in some way.
Target Milestone: mozilla0.9.9 → mozilla1.2
Blocks: 103053
adding self to cc list
Do consider allowing toolbars (and the menu) to be arranged horizontally. My ie
config, when I use it has a compact, three row setup with the 

<- ->         Location: [            ]
Google bar [     ]   File ....... Help
Personal       Toolbar           Links

It would be great for Mozilla users to have this flexibility, too. 
*** Bug 156269 has been marked as a duplicate of this bug. ***
Jason:

> I just noticed attachment 65067 [details], a complete spec for the toolbar
> system redesign, submitted by MPT in bug 49543.  It's quite
> apparent that the work I've done for this bug will not fit in
> that new system whatsoever, so I hereby withdraw my patch
> in favor of moving ahead toward the toolbar rewrite. 

According to bug 22056 comment 100, Marlon stopped working on MPT's spec in
February.  As far as I can tell by sorting a mess of related bugs, nobody else
has picked it up.  So I wouldn't count on the spec being implemented any time
soon at all.  Incidentally, MPT's spec SHOULDN'T have been attached to bug
49543.  It has some tangential relationship (as future nanotechnology does to
current medicine), but no actual direct bearing on the resolution of the bug.

Further, if you look at recent discussion in bug 49543, one suggestion is to
reverse the dependency between that bug and bug 48926.  However, THIS bug is
marked as blocking bug 48926.  So, if no more work is done on this bug because
it's waiting for MPT's spec, which Marlon has stopped working on, which blocks
bug 48926, which would also then block bug 49543 - that would make at least 3
bugs (and there are more indirectly), plus MPT's spec itself, which have had
development halted.

Is there any chance of persuading you to continue with your patch?  Even if, a
long way down the road it becomes obsolete, it would go a long way in the
immediate future towards addressing a lot of problems.
Blocks: 157199
Can we at least get this patch in, then work on bug 48926?
Keywords: patch
What we need is a *real* implementation.  My patch, while perhaps better than 
nothing, is a half-assed one: it only allows vertical rearrangement, gives 
insufficient visual feedback, and resorts to some hacks which might affect 
profile compatibility if it were replaced in the future with a real 
implementation (due to storing ordinal values in localstore.rdf).

If someone else wants to continue development of my patch that's fine, but I'm 
afraid I won't be the one doing it because (1) I don't think it's the right 
thing for the product at this point, (2) I'm not skilled enough, and (3) I just 
don't have the time right now.

I'd rather see a knowledgeable developer attack this and/or the dependencies.  
I'm willing to wait for it to be done right.

(On a side note, I've noticed some great UI customizability in Venkman 
recently; perhaps the code for those floating views can be used as a starting 
place for arrangeable toolbars?)
--> default owner
Assignee: hyatt → jaggernaut
Status: ASSIGNED → NEW
QA Contact: claudius → jrgm
Target Milestone: mozilla1.2alpha → ---
Blocks: 164421
*** Bug 175482 has been marked as a duplicate of this bug. ***
Summary: [feature] Toolbar movement. → Ability to rearrange toolbars (by drag and drop)
Is there any active work done on this bug/enhancement?  It has been many years
since it is opened and it is stil new.

I've installed quite a few plugin from mozdev and they occupies several rows,
even though most of them took less than half of the row.  It would be nice to
arrange them like in IE (I've never been a IE fan).  Otherwise things are too
clumsy.
@Hao Huang : Given the long wait with no reply I think you can safly asume that
the answer to your question is a "no"
This bug seems to have gone stale.

It might also be a thing more suited for Firefox , should we change the
"product" to make it reflect this ?
> It might also be a thing more suited for Firefox , should we change
> the "product" to make it reflect this ?

No.  If it's something desired for Firefox then a new bug should be opened. 
This bug is targetted specifically against Seamonkey.
Considering that (a) the Firefox/Thunderbird XUL has this feature and it
works well, and (b) the Seamonkey frontend is stable and in maintenance
mode, I strongly suspect this bug is really a WONTFIX.
(In reply to comment #55)
> Considering that (a) the Firefox/Thunderbird XUL has this feature and it
> works well, and (b) the Seamonkey frontend is stable and in maintenance
> mode, I strongly suspect this bug is really a WONTFIX.

Exactly HOW does one do this in/with XUL?
*** Bug 303251 has been marked as a duplicate of this bug. ***
Assignee: jag → cst
Component: XP Toolkit/Widgets → XP Apps: GUI Features
Keywords: helpwanted
Priority: P3 → P2
Product: Core → Mozilla Application Suite
Target Milestone: --- → Future
Posted patch patch (obsolete) — Splinter Review
You can reorder toolbars vertically, and you can have multiple toolbars on a
row.  Drag by the grippy.  Drop over another toolbar (see item 3 below).

-1) This patch uses eval().
0) I have a lot of if(0)'ed out dumps.	It still spews a little bit of info in
the constructor / destructor, but you can get a lot more by putting the dumps
back in.
1) Requiring flex on the <toolbar> is probably bad.  I should set it myself in
the toolbox constructor.  That should be safe, because right now nobody should
have anything in which toolbars already flex.
2) Existing ondrag* handlers for toolbars can cause problems, which is why I
modified the personal toolbar folder.
3) Drop over the left or right 15% of the width of a toolbar to drop onto the
same row.  If you drop over the middle 70%, it will go above or below the
toolbar you dropped on.  I picked those constants arbitrarily.	If I could do
stretched images in XUL, some visible indicator would be nice
4) MSIE moves as you drag.  MSIE also makes it VERY hard to get the arrangement
you want, so I move only ondrop, but with much better usability.
5) XBL doesn't like DOM nodes moving around.  Fortunately, the URL bar was the
only problematic thing, and even that has a fairly easy workaround.  I have
seen it occasionally fail to find the url bar in the constructor though, and
I'm not entirely sure it works 100% of the time.
6) The ">>" at the end of the overflowed menu should really stay next to the
splitter no matter how narrow you make the menubar (well, until it's narrower
than the ">>" itself).	For some reason, it won't move more than one menu left
of where it starts.  I have no idea why this is.
7) Toolbar overflow should be hidden or it will be visible in adjacent toolbars
(just the leftmost overflowing item will, the rest won't).  I couldn't get it
to hide from communicator.css so I used inline CSS.
8) I don't do nice collapsing of toolbar contents.  Fundamentally it should be
possible.  I'm not sure if it's worthwhile though... for SeaMonkey 1.1 I'd hope
we have toolkit's customizable toolbars, which would let you have everything on
one line and it would look good (whereas automated collapsing would just chop
off the rightmost toolbar buttons).  Flex elements also create headaches -
there's a long comment in the patch about this.
9) The menubar overflow ">>" button isn't as tall as the personal toolbar
folder's ">>" button.  Oops.
10) The patch would be quite a bit shorter without the dumps.
Posted patch patch v2Splinter Review
(In reply to comment #58)
> 0) I have a lot of if(0)'ed out dumps.	It still spews a little bit of info in
> the constructor / destructor, but you can get a lot more by putting the dumps
> back in.
I removed the dumps.

> 1) Requiring flex on the <toolbar> is probably bad.  I should set it myself in
> the toolbox constructor.  That should be safe, because right now nobody should
> have anything in which toolbars already flex.
Fixed - I set it myself now in the constructor.

> 5) XBL doesn't like DOM nodes moving around.  Fortunately, the URL bar was the
> only problematic thing, and even that has a fairly easy workaround.  I have
> seen it occasionally fail to find the url bar in the constructor though, and
> I'm not entirely sure it works 100% of the time.
It seems to work properly now, and I changed the code a bit to work better for mailnews / things with no URL bar.  Note that it still throws if the thing with the toolbar doesn't include nsDragAndDrop.js.

> 10) The patch would be quite a bit shorter without the dumps.
That's basically what I'm attaching.
Attachment #196963 - Attachment is obsolete: true
Attachment #202850 - Flags: review?(jag)
Attachment #196963 - Flags: review?(jag)
Whiteboard: [cst: probably never happening]
Comment on attachment 202850 [details] [diff] [review]
patch v2

This patch is pretty bitrotted, "now" that bug 282188 is fixed...

> [cst: probably never happening]

Why?
(In reply to comment #61)
> (From update of attachment 202850 [details] [diff] [review] [edit])
> This patch is pretty bitrotted, "now" that bug 282188 is fixed...
> 
> > [cst: probably never happening]
> 
> Why?
> 

I'm not going to write this just for 1.1a, and then do toolkit customization for 1.5, and I am under the impression that toolkit toolbars are definitely not happening on 1.1 so I could just take advantage of their customization support now for 1.1.  I don't see much reason to have both drag-drop and toolkit customization.
-> somebody else
Assignee: cst → nobody
QA Contact: jrgmorrison → guifeatures
Priority: P2 → --
Component: XP Apps: GUI Features → UI Design
Depends on: 172818
At the moment except for tabs most items are customizable. With the option to switch to tabs on tab the remaining problem is solved. This bug should be closed.
(In reply to comment #64)
> At the moment except for tabs most items are customizable. With the option to
> switch to tabs on tab the remaining problem is solved. This bug should be
> closed.

I'm now running the current Firefox 4 nightly and I cannot move File menu anywhere, all other toolbars are also unmovable because there's no handle for them, you just cannot pick them up to drag them.

So, I dare say this bug's far from being resolved.
Guys:
1. This is a SeaMonkey bug not a Firefox bug.
2. This bug is about rearranging toolbars not the buttons in the toolbars.
3. Neil Deakin is currently working on dockable toolbars, so stay tuned.
The firefox bug for this is bug 172818.
Attachment #202850 - Flags: review?(jag-mozilla)
You need to log in before you can comment on or make changes to this bug.