Allow horizontally adjacent toolbars (with splitters)




19 years ago
7 years ago


(Reporter: bozhan, Unassigned)


(Depends on: 1 bug, Blocks: 2 bugs, {arch, helpwanted})

arch, helpwanted
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)


(Whiteboard: [hard][p-ie/windows])


(1 attachment)



19 years ago
If you compare customizaton of Mozilla and IE you will find that
mozilla can't do anything that most of the IE users likes. And specialy putting 
two control bars in the same row. I can't explain this very well with my english 
so i'll post screenshot i mean.
Not a feature slated for release with the shipping Netscape 6 skins or chrome.
Marking WON'T FIX.  Unless PDT changes this, I believe this is correct.
Last Resolved: 19 years ago
OS: Windows 98 → All
Resolution: --- → WONTFIX
Reopening. Technutz, this is the Mozilla bug database. That something isn't 
`slated for release', by one particular management team, for one particular 
version, of one particular commercial Mozilla distribution, is entirely 

Resummarizing to horizontally alignable toolbars, because that's the main point 
in this report, and because other toolbar customization issues are covered 
elsewhere (search for bugs with `toolbar' in the summary to see them).
Severity: normal → enhancement
Depends on: 47584
Hardware: PC → All
Resolution: WONTFIX → ---
Summary: Customiztion of UI isn't very useful → Allow horizontally adjacent toolbars


19 years ago
Ever confirmed: true


19 years ago
Blocks: 49543
Depends on: 15322

Comment 4

19 years ago
Reassigning from bdonohoe to hangas
Assignee: bdonohoe → hangas

Comment 5

19 years ago
I plan on doing this in the C++/XBL code for toolbars.  Taking.
Assignee: hangas → hyatt
--> XPToolkit/Widgets
Component: User Interface: Design Feedback → XP Toolkit/Widgets
QA Contact: mpt → jrgm

Comment 7

19 years ago
Target Milestone: --- → Future
Is this user customisation or just the ability to do something in XUL/CSS?

Comment 9

19 years ago
i think both


18 years ago
Keywords: softui
/me wonders how hard this one is.  Could someone do it with a little help and
advice from hyatt?  Even if only as a background task for mozilla1.0 or 1.1?


Comment 11

18 years ago
you could implement it today w/ <bulletinboard/>, the problem is getting good 
docking and relationship actions(* there has to be a better word, but i'm 

I guess I'd draw gridlines on the bulletinboard background (or fix line widgets 
there, whichever).

Here is a short list of ui impl questions:
a. Do we want Floating Widget Style or Snapto Style (Swing/IE5+)?  [I'm not 
sure if one would be easier.]
i. Outline Dragging?
[Floating does (or can do?) outline, IE+Swing w/ their snapto systems do not]
b. Do we care about overflow?
i. Swing only allows the rightmost toolbar to overflow and provides minimal 
indication (possibly a cropped widget -- depending on what the user did). This 
is also the way Docking toolbars typically behave.
ii. IE has certain minimal widths for right edge and provides a reflow widget 
for Toolbars and Menus (not address bars)
c. Dragging behavior.
i. In Swing, if you drag horizontally against another toolbar, nothing happens 
until you pass the next grippy.
ii. IE lets you crop or force the overflow widget. [again, reorder happens when 
you pass the other grippy]
iii. Floating requires you to drop on/past the grippy. [like Swing, you can't 
squish another toolbar]
d. Should users be able to stretch toolbars (vertically)? -- Apps don't usually 
do this, but IE's shell integration does for taskbar like elements (this is 
useful for people who want 3 rows of bookmarks).
e. Double Click behavior.
i. Swing: nothing.
ii. IE if leftmost then squishes to right edge, otherwise squishes all toolbars 
in its row w/o reorder
iii. Floating: floats :)

--Warning, this is experimentation, not spec reading. Apps: PSP6,IE5.5,NB3.2-38

It seems to me that our xul arch actually works against us here (I'm wondering 
if html is better because of it's reflow tendencies and refusal to be box 
oriented)... this is something that Delphi/C++Builder/VB[/MFC] can all do 
easily by changing 1-3 properties, but we treat everything as oriented and 
parented (or floating) boxes.  ...

The dirty way, which is similar to Swing, would be to use a separators, but how 
do you get it to jump from one row to the other (again, box layout+parent 
ownership working against us) which is a requirement (otherwise you're trading 
one inflexible ui for another).  If people don't mind the extra overhead, we 
could have N copies of each toolbar, or make a copy as needed whenever someone 
'drags' a toolbar to a new row.
Keywords: arch, helpwanted
Whiteboard: [hard][ie-p]

Comment 12

18 years ago
timeless: this couldn't be done in <bulletinboard> unless you wanted to
constrain your floaters to within the toolbar area entirely. this is an old, old
request that we'd love to have in the toolkit -- the original bug is 7696.

*** This bug has been marked as a duplicate of 7696 ***
Last Resolved: 19 years ago18 years ago
Resolution: --- → DUPLICATE

Comment 13

18 years ago
dr: I think you rushed to dupe this.  This is slightly different than bug 7696.  
That deals with having tear-off toolbars, menus, etc.  This bug is about 
allowing toolbars to be horizontally adjacent.  Both work towards the larger 
goal of "funky" toolbars, but I'd prefer if this bug was re-opened so that it's 
not lost in the shuffle.

Comment 14

18 years ago
Dean: do what thou willst. If you choose to reopen this, I'd suggest making an
overarching bug for "better toolbars" and marking all dependencies.
Toolbar movement is covered at bug #15322.  That briefly mentions horizontally
adjecent toolbars.
Verified rush-to-dupement. These are completely different bugs; toolbars do not 
need to be tear-offable to be horizontally adjacent, and vice versa. Reopening.
Resolution: DUPLICATE → ---
Whiteboard: [hard][ie-p] → [hard][p-ie/windows]

Comment 17

18 years ago
all toolkit-owned toolbar enhancements -> ben. nominating moz1.0.
Assignee: hyatt → ben
Keywords: mozilla1.0
*** Bug 94447 has been marked as a duplicate of this bug. ***
I would like to see this (i.e., the ability to set toolbars 
side-by-side to reduce the total vertical hight of all toolbars 
together) applied to all toolbars, including extra ones that
are not shown by default (such as the Site Navigation Bar and
Preferences Toolbar).  The total vertical height of the toolbars
can detract substantially from the available page display area
when multiple toolbars are shown on a small-to-medium display,
but some of them do not need the full width.  For example, the
Personal Toolbar Folder certainly *can* use the full width, 
but some users may not have or need that many links on it.  

For reference:  Preferences Toolbar can be found here:

Adding myself to Cc: list also.


17 years ago
No longer blocks: 49543


17 years ago
Depends on: 49543

Comment 20

17 years ago
adding self to cc list

Comment 21

17 years ago
I think it shouldent be cutomizable the same way as IE but the same way as most
Macromedia products are

Comment 22

17 years ago
Alex, can you provide an example of how Macromedia does it?  I have no idea what
you mean just from reading, since I don't own any Macromedia stuff.

Comment 23

17 years ago
I wonder how the skin (i.e. the color beneath the text) should behave if one
were to move the personal toolbar up horizontally adjacent to the menubar?
Desired behavior would be that the personal toolbar would adopt the skin that is
beneath the menubar, as with the modern or pinball skins, the personal toolbar
is darker than the menubar. You wouldn't want the horizontally adjacent personal
toolbar to be visually jarring against the menubar.

You can understand the problem in vertical terms if you "minimize" or hide the
navigation toolbar. With the personal toolbar now directly below the menubar, it
is darker than the menubar. Imagine is it was "docked" to the right of the menubar.
> I wonder how the skin (i.e. the color beneath the text) should 
> behave if one were to move the personal toolbar up horizontally
> adjacent to the menubar?

The same way it does now.

> Desired behavior would be that the personal toolbar would adopt
> the skin that is beneath the menubar

No.  That way lies madness.  The CSS should be applied to each 
item that applies to that item.  If a themes sets two things to
different colours, it may have a reason (variety, if nothing 
else).  Furthermore, once you change the background of anything,
you must change the foreground as well (or you can get invisible
items), and there are some things on the toolbars that are done
as images for the foreground.  So the theme's colours must be
applies as they stand, in their entirety, unless the user does
something in the user CSS to change it.

> You wouldn't want the horizontally adjacent personal
> toolbar to be visually jarring against the menubar.

It is very possible that a theme *would* want them to be 
_different_ colours.  As far as their being "visually 
jarring", it is up to each theme to select colours that 
go well together (unless (as with FruityGum) the whole 
idea of the theme is to be visually jarring).  As you
point out, it is possible for various toolbars to be
adjascent to one another when the others are collapsed,
so horizontal adjascency does not introduce a new element
here:  the colours of the various toolbars have to look
decent next to one another anyway, for each theme.  This
bug changes nothing about that.  

BTW, I'm all for this bug, but I don't see a realistic
hope that it will make 1.0; perhaps that keyword should
be reconsidered.

Re: Macromedia:  I also have no idea about those products;
perhaps you could describe the specific feature(s) in question?


17 years ago
Blocks: 157199

Comment 25

17 years ago
How is toolbar resizing being handled?  For instance, if two toolbars are joined
together will they each automatically size to take up 50% of the horizontal
space - or is this bug also going to address manual resizing?  (Forgive me if
I've missed something obvious in the previous comments.)  Should a separate bug
be opened for this?
> How is toolbar resizing being handled?  [...]  
> Should a separate bug be opened for this?

Yes.  That's an important thing that dare not get lost in the
shuffle, but this bug could maybe check in without it, especially 
if no toolbars are horiontally adjascent by default.

Comment 27

17 years ago
Can we change the Summary / intent of this bug to "Allow horizontally adjacent
toolbars with splitters."?

If it's made explicity clear that a solution to this bug will necessarily
include a way of resizing the joined toolbars then I can close out bug 158544 as
a "duplicate" - even though, technically, it would only be a duplicate of a
subset of this bug.


17 years ago
Summary: Allow horizontally adjacent toolbars → Allow horizontally adjacent toolbars (with splitters)

Comment 28

17 years ago
*** Bug 158544 has been marked as a duplicate of this bug. ***


17 years ago
Depends on: 164421
Blocks: 164421
No longer depends on: 164421


17 years ago
Blocks: 128963

Comment 29

16 years ago
*** Bug 193601 has been marked as a duplicate of this bug. ***

Comment 31

16 years ago
Should a new bug be created for the same requested functionality under Firebird?
Assignee: bugs → jag
QA Contact: jrgmorrison → xptoolkit.widgets

Comment 32

11 years ago
I think it would be nice to have this at least implemented. GTK allows such things and forces ability of such function with GNOME's GConf key.
Assignee: jag → nobody
You need to log in before you can comment on or make changes to this bug.