Closed
Bug 110313
Opened 23 years ago
Closed 14 years ago
proposal for elegant selecting/searching bookmark folders for storing/selecting bookmarks
Categories
(SeaMonkey :: Bookmarks & History, enhancement)
SeaMonkey
Bookmarks & History
Tracking
(Not tracked)
RESOLVED
EXPIRED
People
(Reporter: andre, Unassigned)
Details
(Keywords: polish)
build: n/a os: n/a repro: yes the "add bookmark" dialogue is uncomfortable dealing with many folders. I have many folders and I always add bookmarks to the new bookmarks folder and have to sort them all 2 to 3 month and that's a pain in the ass. It would be nice to sort them immediately, but mozilla does not support a nice kind of interface. A folder hashtable is needed and a search form for the user. The user starts to enter the folder name and mozilla displays a number (only the number) of matching folders having that substring ang in their name. As the user is comfortable with a comfortable low number of folders (eg. 6) he clicks somewhere (eg. "display matches") and the matching 6 ones are displayed, the user selects one and should be able to a) show the tree somehow: there may be several equally named folders, eg. as a tool-tip on mouse over (eg. Personal Toolbar/Hardware/MP3 Players/) b) jump to the tree (decollapsed to that degree of course ) to consider storing it immediately, in another related folder or to create a new one to store it there rough guess what needs to be done: - hash table (may be already there for other searching purposes) - calculation for substring matches - small gui additions (maybe below "Default folder" there would be enough space estimating that folder names usually are not bigger than 10 to 14 chars and even if they are there is the tool-tip full tree path feature :) ) - display the search results in the box (code may be stolen from the search component) as long as the "search match" isn't changed - display the full path in a tooltip that finally would make using bookmarks more comfortable, this dialogue would not only be practical for adding bookmarks, searching folders and/or bookmarks in general this way is pretty straightforward (compare to the PIM/information manager "Info select", it's pretty cool and uses a graphical sort of display) *sending-hopes*
Reporter | ||
Comment 1•23 years ago
|
||
adding mail3 adding polish (guys I am not sure about this one, but it *seems* to be not the risky/complicated)
Reporter | ||
Comment 2•23 years ago
|
||
removing mail3 (sorry I mixed it up with another bug I am going to file in a few seconds)
Keywords: mail3
reassigning to marlon for UE comments on this proposal
Assignee: pchen → marlon
Comment 4•23 years ago
|
||
this is a great idea. it is my personal vendetta to make bookmarking more usable, and we've been talking about a top down reassessment of bookmarking as a feature. i think this idea is going to be something we will want to work into an upcoming bookmarking redesign. and i'm pushing to have a redesign project sometime in the mach V timeframe.
Comment 6•22 years ago
|
||
ok,I have another addition. If you've ever used galeon, u'll notice that when browsing the bookmarks (either directly from the menu, or in the toolbar (obvsiouly im not talking about in the bookmark manager itself) you can add bookmark to any folder. EG: just dropdown the bookmark menu, navigate, and if you release the mouse on a folder, it lets you add the current page to that folder. note, you should have the same functionality with the folders/sub-folders that exist in the personal toolbar. THIS IS ESSENTIAL !!! it saves so much time and effort. Whoever is watching this bug, reply below, and since im on the cc list, i'll be notified that you have indeed recognized my request.
Comment 7•22 years ago
|
||
just updating as it was not met for 1.0.1
Comment 8•22 years ago
|
||
"Bookmark search" should also return matching folders.
Comment 9•21 years ago
|
||
It would be really nice to be able to Open the Folder That Contains a bookmark after a search. This feature is *very* usefull for easy bookmarks management.
Comment 10•20 years ago
|
||
I still maintain, and have complained several times in the newsgroups, that moz bookmark function has multiple problems that go *backward* from NS 4.8. In one of these messages [news://news.mozilla.org:119/c1dfup$fgl2@ripley.netscape.com], I indicated the following bookmark-specific items: "Other items that went backward from NS 4.x include removal of 'insert separator' from the right-click context menu in bookmarks manager, the scrolling format of bookmarks in a large file, vs. the multi-column wide view [*much* superior, IMO],". In a later post, someone else wrote: "I also have accumulated a large bookmarks file, and really miss Netscape 4's ability to search (find) withIN the bookmarks window -- IOW just advance to and select the (next) matching bookmark within the (context of all the) other bookmarks. " I also agree with this assessment. Finally, in a yet later article [news://news.mozilla.org:119/c2au3h$ga23@ripley.netscape.com] I indicated some additional problems: "1. Even for the toolbar folders into which I can drag/drop links, the list will not scroll, so I am limited to only the range that comes up by default. Also, what I consider the backward movement to the scrolling bookmarks [vs. multi-column format] also impacts this negatively. 2. I cannot drag/drop links into the pulldown-menu bookmarks list at all. " These last 2 issue, though, seemingly are sporadic; occasionally [but not usually] they seem to work. FWIW, moz 1.6/win2k[fully patched]. Sorry if these issues duplicate, but my initial search did not show them on here. I resisted going bugzilla, but finally got fed up and had to provide $.02. Thanks.
Updated•20 years ago
|
Product: Browser → Seamonkey
Updated•17 years ago
|
Severity: normal → enhancement
Updated•16 years ago
|
Assignee: marlon.bishop → nobody
QA Contact: claudius → bookmarks
Target Milestone: mozilla1.0.1 → ---
Comment 11•15 years ago
|
||
MASS-CHANGE: This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614
Status: NEW → UNCONFIRMED
Comment 12•14 years ago
|
||
MASS-CHANGE: This bug report is registered in the SeaMonkey product, but still has no comment since the inception of the SeaMonkey project 5 years ago. Because of this, we're resolving the bug as EXPIRED. If you still can reproduce the bug on SeaMonkey 2 or otherwise think it's still valid, please REOPEN it and if it is a platform or toolkit issue, move it to the according component. Query tag for this change: EXPIRED-20100420
Status: UNCONFIRMED → RESOLVED
Closed: 14 years ago
Resolution: --- → EXPIRED
You need to log in
before you can comment on or make changes to this bug.
Description
•