Open
Bug 47873
Opened 24 years ago
Updated 2 years ago
collapsed toolbars are indistinguishable
Categories
(Core :: XUL, enhancement, P3)
Core
XUL
Tracking
()
REOPENED
Future
People
(Reporter: davidhj, Unassigned)
References
Details
I have all toolbars collapsed and now, when I want to open say the Personal Toolbar, I have to guess which is which because the handles both look the same. A solution would be to differentiate them visually, e.g. by colour or by the width of the collapsed handle. This would also be useful when collapsing toolbars in order to rearrange them (the "unintended feature" mentioned in 37766).
Updated•24 years ago
|
Severity: normal → enhancement
Status: UNCONFIRMED → RESOLVED
Closed: 24 years ago
OS: Linux → All
Resolution: --- → INVALID
Comment 1•24 years ago
|
||
The tooltips that appear when you mouseover the collapsed handle indicate which toolbar it is. In addition, the width of each handle is also different. The "unintended feature" that you refer to never stayed in the trunk - it was a result of the M16 branch. Marking invalid.The tooltips that appear when you mouseover the collapsed handle indicate which toolbar it is. In addition, the width of each handle is also different. The "unintended feature" that you refer to never stayed in the trunk - it was a result of the M16 branch. Marking invalid.
Comment 2•24 years ago
|
||
Actually, David makes a valid point. Tooltips are only a stop-gap measure for making the collapsed toolbars distinguishable. They are not an acceptable solution in the long-term because they require the user to hover over each toolbar in turn to find the one they want. Overall, the collapsing toolbar mechanism needs a serious overhaul. They weren't effective in 4.x and they're no better now. Reopening and marking Future so we can track the issue and resolve it later.
Status: RESOLVED → UNCONFIRMED
Resolution: INVALID → ---
Target Milestone: --- → Future
Brendan you still left this unconfirmed? I'm assuming by error, marking confirmed.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Comment 4•24 years ago
|
||
Actually, I meant to accept it. Thanks for pointing that out.
Status: NEW → ASSIGNED
Comment 5•24 years ago
|
||
I'm gradually coming to the conclusion that allowing the collapsing of toolbars at all is more trouble than it's worth.
Reporter | ||
Comment 6•24 years ago
|
||
Well, it is rather odd that there are two ways to get rid of toolbars: 1. collapse them and 2. deselect them via the View Menu. Why not just have a right-click context menu on the toolbars which lets you select or deselect them. This is what e.g. Word does and it works pretty well as a compromise.
Severity: enhancement → blocker
Component: User Interface: Design Feedback → ActiveX Wrapper
Priority: P3 → P1
Hardware: PC → All
Target Milestone: Future → ---
Comment 7•24 years ago
|
||
* Nothing to do with the ActiveX wrapper. Changing back. * Priority is for the use of the programmer who is fixing the bug. Changing back. * Definitely not a blocker. Does not prevent normal use of Mozilla, or even cause data loss. Changing back.
Severity: blocker → normal
Component: ActiveX Wrapper → User Interface: Design Feedback
Priority: P1 → P3
Reassigning from bdonohoe to hangas
Assignee: bdonohoe → hangas
Status: ASSIGNED → NEW
Marking Future. This toolbar design needs work, but it is too late to take on for this round.
Severity: normal → enhancement
Status: NEW → ASSIGNED
Target Milestone: --- → Future
Comment 10•24 years ago
|
||
Chaning the qa contact on these bugs to me. MPT will be moving to the owner of this component shortly. I would like to thank him for all his hard work as he moves roles in mozilla.org...Yada, Yada, Yada...
QA Contact: mpt → zach
Comment 11•24 years ago
|
||
updating to new owner. sorry for the spam.
Assignee: hangas → mpt
Status: ASSIGNED → NEW
Comment 12•22 years ago
|
||
*** Bug 169160 has been marked as a duplicate of this bug. ***
Updated•22 years ago
|
Assignee: mpt → jaggernaut
Component: User Interface Design → XP Toolkit/Widgets
QA Contact: zach → jrgm
Comment 13•22 years ago
|
||
.
Comment 14•22 years ago
|
||
.
Status: NEW → RESOLVED
Closed: 24 years ago → 22 years ago
Resolution: --- → WONTFIX
Comment 16•22 years ago
|
||
toolbars are back, which I guess mean this is back too..
Status: VERIFIED → REOPENED
Resolution: WONTFIX → ---
Comment 17•22 years ago
|
||
*** Bug 192852 has been marked as a duplicate of this bug. ***
Comment 18•22 years ago
|
||
I don't really think the idea of collapsed toolbars being collored or different widths is the best solution to the problem. With these solutions the user would have to remember width/color corrispondes with which toolbar. IMO, a better solution would be icons or text labels would be a better solution.
Comment 19•22 years ago
|
||
*** Bug 191973 has been marked as a duplicate of this bug. ***
Comment 20•21 years ago
|
||
As it is now, the bars are in the order they were collapsed, that is if I collapse personal first, then menubar, then navigation, thats the order the tabs will be in. A better way (in my opinion) would be to keep the collapsed bars in order, so that the menubar always comes first (if it is collapsed), then navigation, then personal, no matter which was collapsed first.
Updated•16 years ago
|
Assignee: jag → nobody
Updated•13 years ago
|
QA Contact: jrgmorrison → xptoolkit.widgets
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•