All users were logged out of Bugzilla on October 13th, 2018
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.0.1) Gecko/20021125 Chimera/0.6+ Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.0.1) Gecko/20021125 Chimera/0.6+ Having the B&H in a Drawer is perfect for browsing: - with big windows, like users who are using Tabbed Browsing - with few documents opened at the same time in individual windows - with very few and clean named bookmarks - with a very small hierarchy of bookmarks (sub-folders ^n) - with fast computers able to quickly resize a window to show "its" Drawer - with fast computers able to quickly refresh all the windows behind - with a computer with a (very) wide screen All users are not browsing with big windows or under Tabs. Sometimes several windows must be visible at the same time (Stockmarkets, java chats, etc) A work-around, for those who know HTML, would be to use frames. But a lot of sites refuse to see their pages, or parts of it, inside frames. The Drawer disadvantages are: - unusable with small windows or several windows opened (crowded) - slow on windows crowded screen due to the resize/redraw - multiple openings required each time you switch to another window - web pages are bigger 800x600 or 1024x768 making the drawer 'inaccessible' - waste screen space as several drawers might need to be opened - reopened in a new window if previous window was showing it - probably using more memory (RAM) as one Drawer is attached to each window Moving the B&H inside a Palette (AAHIG: application-wide toolbar) has all the advantages of the Drawer plus : - accessible from any window - usable no matter the size of the current window - user can size it and position it without being linked to a window - can be 'reduced/expanded' to its title by a click on its green button (zoom) - spare memory as only one is opened - can be placed on a second screen independently - B&H can be maintained without requiring an empty document that has to be opened, resized, then enlarge the drawer, maintain your bookmarks. Then reduce the drawer, resize the window and close it in order for the next new window to appear 'correctly'. Using a Palette will solve/help the following bugs and it will avoid some of the choices made which are against AAHIG - Drawers : - Bug 160411 Maximize window puts Sidebar out of screen It's not a bug, see AAHIG "...If the user makes a window so big that there's no room on either side, the drawer opens off the screen." - Bug 154862 Drawer state (opened) does not persist btwn sessions - Bug 180002 Bookmark drawer width not applied to new windows. This will lead to confusion, the width is kept but not the visible state; see Bug 154862 - Bug 164180 unable to tab between toolbar and bookmarks in the sidebar - Bug 164193 no keyboard access between browser window (content) and sidebar - Bug 180731 remember if sidebar is open/closed for next new window - Bug 167777 ? Save sidebar position (expanded/contracted) I suppose someone will quickly paste that extract of the AAHIG about Drawers: "Some examples of uses of drawers include access to favorites lists, the Mailbox drawer (in the Mail application), or BROWSER BOOKMARKS." This is just an example and nothing is said against using a Palette instead. Everyone knows the problems with bookmarks, they accumulate very quickly, their name are huge, etc... And even if you clean them, sort them in folders under a nice hierarchy, the Drawer's width will annihilate that cleaning. Using the Bookmarks menu when you have a lot of bookmarks is very slow and not very handy to use when you have a big hierarchy (lots of sub-folders, sub-menu are closing and jumping on left and right). I think we should see the B&H Palette as a B&H Manager window, which of course can also be used to select a bookmark. By using the Green button (zoom) a Palette can be "reduced" to its title bar and expanded very quickly. By dragging it just below the menu bar, it will not take any space on the screen once "reduced", it will just be over a window title bar. I hope I have been able to convince you... sorry for the length. Reproducible: Always Steps to Reproduce:
I doubt Chimera would get this. As I've suggested elsewhere, the sort of fundamental UI changes you've been proposing, while perfectly valid, are probably best done as a Mozilla skin or an entirely separate third-party browser project based either on the Mozilla or Chimera code.
Not going to happen.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → WONTFIX
Sorry to reopen, no offense to Soren. I would like to have Mike Pinkerton or Simon Fraser among others on this one, if they don't mind. Is it a definitive no or just no until v1.0 ? >Anyway, I'm not a Chimera developer. I'm just a triager: I go >through bugs, check them, confirm or resolve them eventually, >etc. My opinion on what should be implemented and what not may >differ from that of Mike or Simon. >Sören 'Chucker' Kuklau >Chimera Wannabe Bug Triager
Status: RESOLVED → UNCONFIRMED
Resolution: WONTFIX → ---
Alright, just let me get this off the infamous huge UNCONFIRMED list. Mike Pinkerton: Please comment if you actually want this (I don't, but this is a matter of preference).
Status: UNCONFIRMED → NEW
Ever confirmed: true
an interesting idea, worth keeping around, but probably not going to happen any time soon.
Target Milestone: --- → Chimera1.2
we already have other bugs on this. i agree the drawer was inappropriate entirely for bookmark management. we have other bugs to cover this discussion, marking wontfix just to get it off the radar (not to reject the idea).
Status: NEW → RESOLVED
Last Resolved: 16 years ago → 15 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.