48926 - Allow horizontally adjacent toolbars (with splitters)

Status: NEW

(Core :: XUL, enhancement, P3)

Description

[Bozhan Boiadzhiev]

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.

Comment 1

[Bozhan Boiadzhiev]

Attachment: This is Customization not that is provided in mozilla

Comment 2

[[e-mail] (gone - use [e-mail] instead)]

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.

Comment 3

[Matthew T (active 1999-2002)]

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 
irrelevant.

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).

Comment 4

[leger]

Reassigning from bdonohoe to hangas

Comment 5

[David Hyatt]

I plan on doing this in the C++/XBL code for toolbars.  Taking.

Comment 6

[Matthew T (active 1999-2002)]

--> XPToolkit/Widgets

Comment 7

[Peter Trudelle]

->future

Comment 8

[Matthew Tuck [:CodeMachine]]

Is this user customisation or just the ability to do something in XUL/CSS?

Comment 9

[Bozhan Boiadzhiev]

i think both

Comment 10

[Brendan Eich [:brendan]]

/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?

/be

Comment 11

[timeless]

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 
tired).  

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.

Comment 12

[Dan Rosen]

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 ***

Comment 13

[:deanis74]

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

[Dan Rosen]

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.

Comment 15

[Matthew Tuck [:CodeMachine]]

Toolbar movement is covered at bug #15322.  That briefly mentions horizontally
adjecent toolbars.

Comment 16

[Matthew T (active 1999-2002)]

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.

Comment 17

[Dan Rosen]

all toolkit-owned toolbar enhancements -> ben. nominating moz1.0.

Comment 18

[Mats Palmgren (inactive)]

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

Comment 19

[Jonadab the Unsightly One (Nathan Eady)]

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:
http://xulplanet.com/downloads/view.cgi?category=applications&view=prefbar

Adding myself to Cc: list also.

Comment 20

[Ian Pottinger]

adding self to cc list

Comment 21

[Alex Hosking]

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

Comment 22

[Warner Young]

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

[Justin Watt]

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.

Comment 24

[Jonadab the Unsightly One (Nathan Eady)]

> 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?

Comment 25

[Jason Bassford]

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?

Comment 26

[Jonadab the Unsightly One (Nathan Eady)]

> 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

[Jason Bassford]

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.

Comment 28

[Jason Bassford]

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

Comment 29

[Alfonso Martinez]

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

Comment 30

[djk]

The demo from duplicate bug 158544 is here

http://bugzilla.mozilla.org/attachment.cgi?id=93301&action=view

Comment 31

[Aaron Kaluszka]

Should a new bug be created for the same requested functionality under Firebird?

Comment 32

[u294409]

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.