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.

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

Reassigning from bdonohoe to hangas

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

--> XPToolkit/Widgets

->future

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

i think both

/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

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.

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

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.

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.

all toolkit-owned toolbar enhancements -> ben. nominating moz1.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: http://xulplanet.com/downloads/view.cgi?category=applications&view=prefbar Adding myself to Cc: list also.

adding self to cc list

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

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.

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?

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.

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.

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

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

The demo from duplicate bug 158544 is here http://bugzilla.mozilla.org/attachment.cgi?id=93301&action=view

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

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.