158544 - Resizable toolbars.

Status: VERIFIED DUPLICATE of bug 48926

(Core :: XUL, defect)

Description

[Jason Bassford]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.1b) Gecko/20020719
BuildID:    2002071911

With the other bugs that are synergistically encompassing MPT's toolbar
customizability spec, especially bug 48926, bug 49543, and bug 15322, we need to
be able to dynamically resize toolbars.

This is not something that needs to be done prior to the implementation of one
or the other of the above bugs, but it shouldn't be neglected.

Comment 1

[Matthew T (active 1999-2002)]

Why do we need resizable toolbars? Resizable in which direction?

Comment 2

[Jason Bassford]

Horizontally.  There is little point is being able to combine toolbars unless
the individual components can be resized.  See bug 48926 comment 26.

Comment 3

[:deanis74]

I haven't tried it, but it looks like google bar already has something like
this.  See http://googlebar.mozdev.org/screenshots.html.

Comment 4

[Matthew T (active 1999-2002)]

Worksforme, build 2002072103. Mac OS 9.2.2.

To reproduce:
1.  Resize a window to be wider than it was.

What should happen:
*   The toolbars get wider too, all by themselves.

What actually happens:
*   The toolbars get wider too, all by themselves.

Comment 5

[John Levon]

That is soo not productive. Don't pretend to misunderstand. If you
want to WONTFIX it, do so, but WFM is not helpful.

IF you want to continue to pretend you don't know what this bug's
about, when bug 48926 is fixed, this bug is asking for a way to alter
the relative widths taken up by each side-by-side toolbar.

Comment 6

[Jason Bassford]

MPT: You're being deliberately obtuse.  Reopening.

Comment 7

[Aaron Kaluszka]

I think that XUL already has the support for this.  Fixing bug 48926 would
(should) automatically integrate this.  Otherwise the sidebar (already
implemented) wouldn't work, etc.  I don't see how this bug is necessary.  It
really is WFM.

Comment 8

[Jason Bassford]

I asked the question in bug 48926 25 what would happen to the size of the two
toolbars when they were combined - if they would each automatically size to 50%
or if the could be resized manually "to taste".  I didn't get a direct answer,
but was told I should open a separate bug to address the issue - which is this one.

Are you saying that the fix for bug 48926 will include a "resize grippy"?  If
so, then perhaps you're right - but no code has yet been checked into that bug
so there's no way of confirming.  If that bug does end up being fixed in such a
way, and there's nobody who wants a single toolbar to be resized, then I'd be
happy to see this bug resolved as INVALID.  But, until then, I think this bug
should stay open.

Comment 9

[jag (Peter Annema)]

This bug is either worksforme or a dupe of bug 48926. Toolbars, like all other
XUL boxes, can be made any size using splitters. Part of the implementation of
bug 48926 should include inserting a splitter between the two toolbars.

Comment 10

[Jason Bassford]

1. Currently toolbars cannot be resized, neither on their own nor with
horizontally adjacent toolbars using splitters.  So, it's not WORKSFORME.  The
functionality doesn't yet exist.  (There is no need for it yet, which is why
it's marked Future.)

2. Bug 48926 has not yet been implemented, so there's no way of confirming that
when it is there will be a splitter used.  It may be a logical assumption, and
it may very well be what will happen, but until a patch is reviewed and checked
in containing one, this can't be marked as a duplicate.  (If a patch is checked
in for bug 48926 that does *not* contain a splitter, even if it should, and each
of the toolbars take up 50% of the space automatically, then this bug will not
have been fixed.)  If bug 48926 is checked in with a splitter I would be more
than happy to, at that time, mark this bug as INVALID.

Comment 11

[jag (Peter Annema)]

Attachment: demo of toolbars that can be resized using splitters

There seems to be a bug so the text on the buttons doesn't correctly get
cropped or clipped, but in essence these toolbars are resizable.

Comment 12

[timeless]

jag, that bug is ancient and is visible in the sidebar (both horizontally and
vertically)

jag's demo verifies that there is indeed no problem that doesn't work for us.

Comment 13

[Jason Bassford]

> jag's demo verifies that there is indeed no problem that doesn't work for us.

<sigh> This is tiring.  I have no doubt that demos could be made of any number
of features that aren't currently part of Mozilla.  But just because you can
demo something, doesn't mean that it's made its way into the core code and is
actually "working" in a downloadable build.  WONTFIX is the wrong resolution. 
However:

I am reopening this bug so that I can mark it as a (partial) duplicate of bug
48926, now that its summary / scope has been explicitly changed to include
toolbar resizability.

Jag: Why don't you attach your code to bug 48926?  Currently, the only thing
there is a screenshot of IE.

Comment 14

[Jason Bassford]

*** This bug has been marked as a duplicate of 48926 ***

Comment 15

[jag (Peter Annema)]

Jason: I'm not quite sure I understand the point of this bug then.

In your first comment, you say: "we need to be able to dynamically resize toolbars."

That can be read in many ways. One way is to say that all toolbars need resizing
widgets so users can arbitrarly size them. I would WONTFIX such an RFE. Another
way to read it is to have support for a widget that can be placed between two
toolbars on the same row so that the relative widths of those two toolbars can
be changed, without changing the total width. Such a widget already exists, and
addresses "we need to be able to dynamically resize toolbars".

Basically what this bug is asking for then is that when fixing bug 48926 we make
sure that when two toolbars are placed horizontally next to each other, that we
always insert a splitter. That should be dealt with in bug 48926, I think, so
I'll agree to your DUPE resolution.

Comment 16

[:deanis74]

There's another bug with the sample, too, in that using <toolbar> puts a
collapse widget at the left edge of each toolbar.  We'd only want this once per row.

Comment 17

[Christian :Biesinger (don't email me, ping me on IRC)]

do we? do we not want this once per toolbar?

Comment 18

[:deanis74]

That would be a very confusing UI.

Comment 19

[Jason Bassford]

People, this bug is closed as a duplicate of bug 48926 - please take the
discussion there.  (This sample code should be attached to the other bug.)

Comment 20

[Jason Bassford]

Verifying resolution of all bugs I've reported.