Open Bug 172818 Opened 22 years ago Updated 2 years ago

Allow movement of toolbars (using visible grippies)

Categories

(Toolkit :: Toolbars and Toolbar Customization, enhancement)

Product:
Toolkit
Component:
Toolbars and Toolbar Customization
Type:
enhancement

Tracking

()

People

(Reporter: djst, Unassigned)

References

(Blocks 2 open bugs)

Details

Attachments

(2 files)

DHTML version of IE like coolbars
10.30 KB, application/zip
Details
initial XBL implementation
14.71 KB, application/zip
Details 
This is related to bug 171702, which is about enabling toolbar placement at the
right side of the menu bar.

This RFE is about making the whole toolbars movable. When the toolbar
customization dialog is visible, there should also be a visible toolbar grippie
at the left of each toolbar, including the menu. This would allow you to easily
move around the toolbars and combine toolbars on one row. It is already possible
to combine toolbars on one row, but that requires moving the individual buttons.
This would be a way to move the toolbars as a whole. In order to make this
really useful, the menu must also become a toolbar. I do NOT mean that the menu
bar would be customizable, but it should be placed on a separate toolbar
container, to allow moving it and placing other toolbars on each side of it.

The visual toolbar grippie I mentioned could also be displayed while not
customizing the toolbars (to allow moving the toolbars all the time, like IE
does it when the toolbars are not locked), but I leave that decision to the
developers.

Just to clarify: This is NOT a request for dockable/undockable toolbars and this
is NOT a request for moving the individual menu elements or customizing the menu.
not for a while. -> After 1.0
Target Milestone: --- → After Phoenix 1.0
If/when this is implemented in Phoenix, please allow ths toolbars to be locked,
thereby removing the "grippies" from the toolbars.  

IE 6 does this with a "Lock the Toolbars" menu option which removes the grips
from the toolbars and locks them in place.

This would help reduce the probability of accidental rearrangement of the
toolbars, something that seems to cause new users a great deal of stress.  In
particular, I work with developmentally challenged adults who get very
frustrated when toolbars can't be found because the previous suer had managed to
move them into unfamiliar locations.
That could be avoided by only displaying the visual grippies when the Customize
Toolbar dialog was visible, and thus only allowing movement then.

I really think the target milestone for this should be before 1.0. This would
really increase the usability of the toolbar customization.
I have a HTML/CSS/DOM implementation of this working (IE style coolbars). Maybe
I should port this to XUL?
Erik, are you saying that you can make a patch for this?
No, There is currently a bug (#178519) in Mozilla which prevents this from
working satisfactory.

Once that is fixed it should be possible to change my components from XHTML/CSS
to XUL/CSS and then I might be able to produce a patch.


*** Bug 196540 has been marked as a duplicate of this bug. ***
Seems that #178519 is fixed. What about moveable toolbars now? Are you still
there for patching it Erik?
Even though bug #178519 is fixed I still have the problem that #178519 should
have fixed for my prototype of the tool bars. Maybe I should post the prototype
here and then someone else might figure out why the mouse events do not work.
Once the mouse events do work some serious work is needed to translate the
HTML/DOM/ECMAScript prototype into commercial quality XUL/XBL code.
*** Bug 213674 has been marked as a duplicate of this bug. ***
Taking QA Contact
QA Contact: asa → bugzilla
Erik, can you attach your code here, please, so that interested folks (like me
;-) ) can have a look at/into it at least?
By request of kd-moz@tprac.de I'm posting what I've got.

Note that this is a very (VERY) rough DHTML version. There are several bugs but
if anyone wants to base a XUL/XBL implementation of this I'd be glad to help
out in any way possible.
Would resolving this "bug" mean that one can move toolbars that currently on the
top to the bottom and vice-versa? Or are the grippies only for movement along
their current (top/ bottom) positions? Just clarifying ... 
*** Bug 214650 has been marked as a duplicate of this bug. ***
It is possible to move buttons freely and add new toolbars, so this bug seems
obsolete to me.

Even if it is a little bit longer to move toolbars in this way, it is possible
to do it.
Regarding comment #16 from Erwan Loisant: I think the average end-user would
rather have 'visible grippies' where they could drag the toolbars where-ever
they wish. Why send the user through another right-click option menu? Dragging
is a lot easier / obvious.

Also, I agree with comment #2 here by Jackson Fox. Locking of toolbars is
something that I feel would be necessary to prevent accidental movement.
I would really like to see this feature added. 
Erik, bug #178519 is fixed, what now?
I have no plan of continuing this at the moment (or any time soon). Like I said
before:

"Note that this is a very (VERY) rough DHTML version. There are several bugs but
if anyone wants to base a XUL/XBL implementation of this I'd be glad to help
out in any way possible."
*** Bug 248350 has been marked as a duplicate of this bug. ***
Flags: blocking-aviary1.0?
if a patch appears, maybe, but I doubt it'd be low-risk enough at this point.

We're not going to block on this.
Flags: blocking-aviary1.0? → blocking-aviary1.0-
This extension, Firefox Toolbar, has a bit of a toolbar.  Not like IE's but
maybe it's a start to an end?

http://www.firefoxtoolbar.com/ See the photo right at the top!

Toolbars would eb useful for the bookmarks toolbar.  Since not all of us keep it
on a third toolbar but put it together on another, being able to decide it's 
width would be nice.

(just another argument for visible grippies, not for a new extension ^_^)
(In reply to comment #23)
> This extension, Firefox Toolbar, has a bit of a toolbar.  Not like IE's but
> maybe it's a start to an end?
> 
> http://www.firefoxtoolbar.com/ See the photo right at the top!
> 
I do not see how this is relevant here. This bug is about the ability to move
all the toolbars of FF around ... e.g. put them side by side or change their
order of appearance. The extension you cite here is just another extension that
*adds* such a toolbar but does not implement any of the features requested here. 
(In reply to comment #24)
> (In reply to comment #23)
> > This extension, Firefox Toolbar, has a bit of a toolbar.  Not like IE's but
> > maybe it's a start to an end?
> > 
> > http://www.firefoxtoolbar.com/ See the photo right at the top!
> > 
> I do not see how this is relevant here. This bug is about the ability to move
> all the toolbars of FF around ... e.g. put them side by side or change their
> order of appearance. The extension you cite here is just another extension that
> *adds* such a toolbar but does not implement any of the features requested here. 

Like I said I thought someone could improve on it 

*** Bug 264545 has been marked as a duplicate of this bug. ***
*** Bug 264510 has been marked as a duplicate of this bug. ***
Blocks: 254687
Assignee: hyatt → bugs
I would also like to see this fix implemented. I had been reluctant to move to
Firefox because I didn't know it had extensions for the Google and Yahoo
toolbar, which I use all the time. I was pretty psyched to join the Firefox club
at that point. In that other browser, I could park the toolbars on the same row
and only have two bars taking up real estate. 
The current functionality does not let you move buttons from toolbar extensions,
so I am stuck with a lot of unused grey toolbar space eating into my screen...
(In reply to comment #28)
> I would also like to see this fix implemented. I had been reluctant to move to
> Firefox because I didn't know it had extensions for the Google and Yahoo
> toolbar, which I use all the time. I was pretty psyched to join the Firefox club
> at that point. In that other browser, I could park the toolbars on the same row
> and only have two bars taking up real estate. 
> The current functionality does not let you move buttons from toolbar extensions,
> so I am stuck with a lot of unused grey toolbar space eating into my screen...

Ditto. I think this will be a big usability improvement with even more increase
in appeal. Saves a lot of screen real-estate when Google and yahoo can be on
same row
Component: Toolbars → Toolbars and Toolbar Customization
Flags: blocking-aviary1.0-
Product: Firefox → Toolkit
Target Milestone: Future → ---
http://forums.mozillazine.org/viewtopic.php?p=1356728#1356728
 combining extension toolbars into 2 rows
I have 2 extension toolbars, the autoform and the curency converter which i
wanted to combine into one row. it doesn't seem possible to do this with your
method of customize toolbars, as these are extension toolbars. of course your
method works for the basics, no problem, but the add ons pile on vertically when
then can be more efficiently arranged to take up less space on a 15.4 inch screen.
If anyone knows how to line up the toolbars horizontally, as modules, like in MS
word, next to each other in one row, kindly inform otherwise I'd like to see
this in an update. thanks.
Blocks: majorbugs
No longer blocks: majorbugs
yes would like to see this in Firefox, the same way it is used in IE
Assignee: bugs → nobody
QA Contact: bugzilla → nobody
This is an XBL implementation I wrote in June. It isn't in usable state yet,
but I'm putting it here because it doesn't look like I'll be working on it
anytime soon. (In order to be usable, this needs [at least] a few bugfixes in
my code, chevron implementation, bug 309914 to be fixed, and more.)

Attached is a ZIP file, which can be extracted to extensions/ folder in Firefox
1.5 or later for testing.
*** Bug 317532 has been marked as a duplicate of this bug. ***
*** Bug 332620 has been marked as a duplicate of this bug. ***
Working extension here!:

https://addons.mozilla.org/firefox/3571/

It works similar to IE using an lock/unlock toolbars menuitem, and when unlocked, visible grippies appear and you can reorder the toolbars by drag and drop.
QA Contact: nobody → toolbars
Blocks: 15322
Blocks: 562396
bug 474590 is a dupe of this.

Also http://enndeakin.wordpress.com/2011/03/02/fun-with-toolbars/ it would appear this is being worked on.
Since 4.0 the Bookmark bar is invisible, if an App-Tab, e.g. Add-on Manager, is in view.
I like the Bookmark bar to be moved on top of the Tab bar, so it is visible/usable all the time.
(In reply to comment #42)
> Since 4.0 the Bookmark bar is invisible, if an App-Tab, e.g. Add-on Manager,
> is in view.
> I like the Bookmark bar to be moved on top of the Tab bar, so it is
> visible/usable all the time.

Mozdevs don't give a **** about what you want.
As a plain user, just like you - I also want the same thing you described.
So I wrote this userstyle, which you can either put to userCrhome.css file in your profile's folder (if there is no such a file - create it), or use Stylish addon for that.

/* Show bookmark panel when Аdd-Оns Мanager is opened */
#main-window[disablechrome] #navigator-toolbox[tabsontop="true"] > toolbar:not(#toolbar-menubar):not(#TabsToolbar):not([collapsed="true"]) {
   visibility: visible !important; }

/* Set toolbars order */
#PersonalToolbar { 
   -moz-box-ordinal-group: 8 !important; }
No longer blocks: 254687
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: