chimera rfe, similar to bug 174778 for mozilla: have an "open in tabs" menu item at the end of each bookmark folder. this is a feature which phoenix 0.3 has, where all the items in a given bookmarks folder could be loaded as tabs in the current browser window. the behavior in phoenix (similar to chimera) is to *replace* the current browser contents, not additive. would this be useful, do you think, or merely complicate the ui? the possible disadvantage is when a user has a large number (eg, over the current 16 tab limit in chimera) of items in a folder, they might not all load.

Seems too geeky for chimera.

v

Re-opening to see if this is still a WONTFIX: The current set-up makes a the menu a second-class citizen when compared to the bookmark bar (and the bookmark manager) since the bar lets you open a folder in tabs but the menu doesn't. Yes, you can make tab groups explicitly, but I find that highly annoying since if you have a folder where you sometimes want one item, but sometimes want all of them, you have to make two folders (essentially making your own 'open in tabs' feature for that folder) and remember to keep them both up to date. As a result, I've actually switched my primary usage from the menu to the toolbar, and I would imagine that many people who use tabs primarily have either done the same or are just cursing the menu. Shouldn't we strive to make both as useful as possible? Obviously there are things (e.g., drag and drop) that aren't possible for the menu, but other than that feature parity seems like a plus. If the opinion is that it's still too l33t for standard users, we could tie it to a pref like Safari (yes, that means a new pref, but to me this seems important enough to warrant considering it). Alternately, we could make it a folder-by-folder pref in the bookmark manager info window; instead of a checkbox for being a tab group, it could be a radio-button list something like ( ) regular folder ( ) tab group ( ) folder with tab group option Those titles suck, but you get the idea. Or, just shut me down and WONTFIX this again ;)

I think you have come up with one woderfull idea here Stuart. This would ensure Camino doesn't look geecky by default but would let those with interest enable it for the folders they want. It migh be interesting to see if a "do this will all enclosed folders" would be necesarry. Or maybe a more general pref attached to the root bm folder for Bookmarks men and BM bar only. So you could set the prefs you made up using the info panel for the root folders or a pref in the pref panel. As far as I'm concerned we could just implement the phoenix/safari way straight on. It could live well beside the tab groups. Especially since we have this feature already in the bookmarks manager trough contextual menu's.

> As far as I'm concerned we could just implement the phoenix/safari way straight > on. It could live well beside the tab groups. Especially since we have this > feature already in the bookmarks manager trough contextual menu's. I agree with this. Currently every other major browser on the Mac has this behavior (excluding IE), I think worrying about it being "too geeky" is overkill--although I don't think being a simple, novice- friendly browser should really be Camino's goal now anyway.

apple has made this more mundane and people find it useful and missing when they go to switch. i think we should give it a try.

almost too simple. we really should take this on the branch as well.

also need to add a "Open in Tabs" to the localizable.strings file when i land it. please to be giving of the review.

+ if (aFolder != [[BookmarkManager sharedBookmarkManager] bookmarkMenuFolder] && childCount > 0) { Just to clarify the logic here a bit, though it is technically fine as-is, perhaps you could add some parentheses around the statements on either side of the && ---------------------------------------------- NSLocalizedString(@"Open in Tabs", nil) I think this should be NSLocalizedString(@"Open in Tabs", @"Open in Tabs") as IIRC, it gives a helpful error message to translators when something goes wrong with the call. ---------------------------------------------- action: NULL keyEquivalent: @"" there shouldn't be spaces between the ':' and the argument. Also, NULL should probably be nil for the sake of convention. ---------------------------------------------- None of this requires me to re-review, so r+ when its taken care of.

landed on trunk and branch

vrfy'd fixed with 2005011808-trunk (10.3.7).