User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.6) Gecko/20050323 Camino/0.8.2 Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.6) Gecko/20050323 Camino/0.8.2 Currently, bar bookmarks are under menu bookmarks in that menu. This should be reversed since bar bookmarks have a more prominant position. Reproducible: Always

i don't follow. bookmark bar items aren't in the bookmarks menu.

I apologize. I didn't specify. In the add bookmark menu for the add bookmark dialogue. Sorry.

agreed, this is annoying for me as well.

It matches the bookmark manager order so both should change if one does.

will you confirm it, Mike?

I think there's no need to implement this. The current version of Camino remembers the last selection within the "add bookmark" dialog, so if you set it to "bookmark bar" it'll stay there (besides the fact that dragging a bookmark to the bookmark bar is faster anyway). I don't know whether the last selected bookmark folder is retained through restarts of Camino, if this is not the case, the initial poster should file another bug report (perhaps there is one already).

But if you have lots of folders in your Bookmarks Menu, you have the evil UI of a long scrolling list to navigate in order to select the Bookmarks Bar in the first place.

(In reply to comment #7) > But if you have lots of folders in your Bookmarks Menu, you have the evil UI of > a long scrolling list to navigate in order to select the Bookmarks Bar in the > first place. This has been bugging me, too. What about using an NSBrowser (Simon hates these ;) ) or a folders-only NSOutlineView?

How about we copy the Open/Save dialogs to some extent: in small mode, have a popup with some recently used places. In expando mode, show an outline view or browser.

That is a superb idea.

Bookmarks Bar should be the top item in the Bookmarks manager too. Being more visible than the Bookmarks Menu, the bar should be given priority when it comes to usage and it's not like Firefox where the Bookmarks Toolbar is actually part of the Bookmarks Menu. With Camino's Bookmarks manager already resembling Safari, this would make it easier when people switch between the two. The Open/Save dialog box sound like an excellent idea. Even better if the Bar is made the default and above the menu ;). Why am I pushing the Bar for priority? Because apart from being already visible unlike the Menu, it's there for the mostly used and visited bookmarks, at least that's my understanding.

OK everyone, this idea will clean up that pop-up menu once and for all; The menu would display "Bookmarks Menu" and "Bookmarks Bar", and it would also display the folders in the ROOT level of the Menu and Bar (indented to the right). But here is the key, it only displays folders in the ROOT. Any folders in THOSE folders are in a submenu of that folder’s menu item. For example, in my Bookmarks Bar I have 6 folders, Mac-iNet, Personal, Work, Miscellaneous, Bookmarklets, and Follow Up. When I click the "Create In" pop-up menu in the "Add Bookmark" sheet I would see Bookmarks Menu, with it's root folders listed just below it (NOT INDENTED, AS IT'S NOT NEEDED!) and below that, a menu separator, then Bookmarks Bar, with it's 6 root folders (mentioned above) just below it. So if I hover over "Mac-iNet" I would get a sub-menu with the folders that are in "Mac-iNet" and choose one of those folders, or just choose “Mac-iNet” itself, since sub-menus can be selectable items in Mac OS! This cleans it up in two ways. 1. Shortens the menu, if your folders are nested in other folders. 2. Gets rid of the tabbing in the names of folders that are nested deep. (looks strange, let me know if you want a screenshot)

Using submenus for folders will produce a menu with lots of nested submenus for some users, which will be difficult to use.

(In reply to comment #13) > Using submenus for folders will produce a menu with lots of nested submenus for > some users, which will be difficult to use. No, it's actually harder to use one really long scrolling menu. Users would be quick to catch on and navitgate through the heirarchy they setup.

My guess is that 90% of users have less than 10 bookmark folders. For that 90%, one flat menu with indenting is much easier to use than a shorter menu with submenus.

Unfortunately, we can't make that assumption. I think for consistancy sake, sub-foldering should be used because of their popularity in other browsers, such as IE, Safari, and Firefox. The consistancy has proven them effective in most browsing solutions so it would be best to just do what Firefox does: use subfolders.

(In reply to comment #12) I don't like the submenus idea. Submenus are too hard to navigate. The best idea is (I beleive): I think that I value a lot the drag&drop approach because the add bookmark dialog does not work very long. The menu to select where you want to add the bookmark could be very long and it is confusing to use. Instead of this menu, I think we should have columns so we can navigate through like in the Finder. But we already have that, you just have to show the bookmarks page as the selector in the dialog and put it in a sheet we can extend so user having a lot of bookmarks are to going to able to find where to add it very easily. Isn't the best possible solution?

(In reply to comment #9) > How about we copy the Open/Save dialogs to some extent: in small mode, have a > popup with some recently used places. In expando mode, show an outline view or > browser. This is a great idea. Let's do it. But not for 1.0. :)

(In reply to comment #6) > I don't know whether the last selected bookmark folder is retained through > restarts of Camino, if this is not the case, the initial poster should file > another bug report (perhaps there is one already). The value isn't retained through restarts. New bug filed: bug 328737

See also the semi-related bug 159230.

(In reply to comment #18) > (In reply to comment #9) > > How about we copy the Open/Save dialogs to some extent: in small mode, have a > > popup with some recently used places. In expando mode, show an outline view or > > browser. > > This is a great idea. Let's do it. But not for 1.0. :) > My vote would be on this one, sort of like the way Firefox 1.5.0.x implements this.

Morphing this bug into what it actually is (comment 9).