implement "favorite/favourite" folders instead of, or in addition to, a most recently used folder view, mscott and I were talking about doing a favorite folder view. changes to make: 1) change the "folders" label above the folder pane to be something clickable, maybe some text with an icon, where the text cycles between "all folders" and "favorite folders". clicking would alter the <conditions> in the folder pane xul template (or how ever david is doing the global inbox stuff) 2) add to the folder context menu "Add to Favorites", which would have a check mark. 3) for showing things in the folder pane when in "favorites" mode, the logic would be: "the current folder is a favorite, or any of it's children are favorites, but it's not being hidden because it's a global inbox". 4) perhaps "isFavorite" would be a bool attribute on nsIMsgFolder, persisted in panacea.dat 5) this context menu would not appear for accounts (we'd follow the logic in #3 to determine to show accounts or not) 6) by default, we'd make all special folders as "favorites" or something.

I just thought of another improvement we could make to this idea. What if we created a new data source or took the existing account manager datasource and applied a template rule to only show folders that were marked as favorites? When the user goes into Fav Folder view, we would end up with a view like this: + Favorite Folders Inbox Sent netscape.public.mozilla.org.mailnews My Work RSS Feeds i.e. it looks like there is only a single account called "Fav Folders" with the favorite folders as child nodes. My thought / hope is that this wouldn't break too much of the existing UI / command updating. Most of the UI is driven by which folder is selected and we aren't mixing and matching types within the folder (which is one complication of real virtual folders), so hopefully none of that would have to change.

so instead of a view (favorite folders), it would be a new virtual account, with the favorite folders as sub-folders. Our datasource, in either case, would have to make sure that we never returned children from the favorite folders, so in case we had a favorite folder that also had a bunch of children, we wouldn't show the children. (at least I assume that's what we'd want). But if we're showing sub-folders as if they're top level folders, then we could get some ambiguity if two sub-folders have the same name...just rambling out loud... I really don't think true cross-folder virtual folders are going to be that hard. Command updating will be a little bit tricky, but most commands just care that there is a message selected, not what kind of message it is or what kind of folder its in.

Implementation ideas from David: mscott: would you envision a new class that maybe replaces nMsgFolderDatasource? mscott: a favorites data source? mscott: or something that integrates with the exsting stuff David: I think Seth's idea was just a new rule mscott: but uses a rule for hiding David: yeah mscott: but does that new rule scale for showing all Folders under a Favorite Folder fake acct? David: I think the rule approach, if we can get it to work, would be a lot easier. David: ah, no David: I'm not an expert, but I think the rule thing would only work if we showed them in their existing hierarchy mscott: yeah mscott: that's what i thought too David: the thing is, it might be really easy David: I don't remember how far Seth got... David: the separate account thing doesn't even really need to be a different data source, I don't think... David: just a new root folder object mscott: and that object knows how to get the list of folders to show David: yeah, it just has a root folder with mSubfolders David: like any other root folder David: it just knows how to populate mSubfolders David: so it overrides GetSubfolders David: so it would be a new folder class, I guess... mscott: where do you think this implementation would live? mscott: nsMsgFavoriteFolders.cpp mscott: something like that? mscott: in base\src David: yeah, I think so. David: and I suppose a favorite folders server David: so we'd need a new URI base for it.. David: for the root folder David: favorite folders would be pan protocol, right? mscott: yeah anything could be a favorite folder David: so populating it would probably involve querying all the account root folders for their "favorite folders"? mscott: the URI base would be just for the folder mscott: for the root folder mscott: every child folder uses it's own uri David: righyt mscott: do we need a nsMsgFavoriteFolder at all or can we do it all in the server? David: oh, you know... David: the parent folder thing is a problem mscott: don't we do folder.server? David: right now, folders know their parent. David: and then get the root folder? David: probably in most cases. David: but there are times we do folder.parent David: and then we stop when we get to the server... David: it might not be a problem, but we'd definitely have to check. mscott: yuck David: definitely a break down of the Model View stuff David: it's probably not that bad. David: I don't think we can do it all on the server David: there has to be a root folder object that overrides getsubfolder David: unless we rearrange a lot of code mscott: ok David: although, here's an idea :-) David: use an nsMsgDBFolder David: and preflight the population of the mSubFolders David: maybe the parent thing is ok mscott: so no fav folder subclasss? David: if we can get away with using nsMsgDBFolder... David: when we create the fav folder server object mscott: keep typing...brb David: so we have a new account type for favorite folders, and a new server object (or can we use nsMsgIncomingServer?...need to go look at how the server objects are created when we load accounts...) David: I have a feeling might go down the path of trying to use the base classes, and then we'll find some place where having sub-classes would be helpful.... but the whole thing could be fairly easy - all we're doing is aggregrating David: I think a new server class/object is the easiest way to go. mscott: cool mscott: i'll add your notes to the bug David: nsMsgAccountManager::createKeyedServer creates a contract id for the server object David: then, calls GetRootFolder on the server object David: our sub-class can check an initialized flag, and in GetRootFolder, calculate all the sub-folders there, the first time its asked mscott: and that's mSubFolders David: right mscott: don't we still need a fake favorites folder sub class so we actually have a fake acct entry in the folder pane? mscott: or are you thinking we fake it by having the server mscott: make up a dbfolder instance for the root mscott: plus mSubFolders David: I'm not sure what the account entry is based on... David: but doesn't that happen in js? David: in which case, we can just check the account type

pushing off

(In reply to comment #2) > ambiguity if two sub-folders have the same name How about adding the root's name to the end of the folder's name: + Favorite Folders - Inbox (MyName@MyHost.net) - Inbox (MyOtherName@MyOtherHost.net) - netscape.public.mozilla.seamonkey + MyName@MyHost.net - Inbox - Templates Of course, this will not help if there are several favorits from sub-folders wihin one root folder that have the same name, but that would hopefully be pretty rare. Perhaps a *tooltip* with the *full path* would help: [ MyName@MyHost.net / Work Stuff / Downloads ] [ MyName@MyHost.net / Home Stuff / Downloads ] It would also be nice to be able to *sort* the favorites via drag/drop. This could be really cool. :-)

(In reply to comment #1) > i.e. it looks like there is only a single account called "Fav Folders" with > the favorite folders as child nodes. The main reason I like Outlook's Favorite Folders is because they are "stuck" in the UI -- no matter how far I scroll up and down in the list of accounts and folders my favorite folders (and their mail counts) are still right there at the top, only one click away. If a Favorite Folders virtual account was implemented could it somehow be anchored to prevent it from being pushed out of view when scrolling down?

(In reply to comment #5) > + Favorite Folders > - Inbox (MyName@MyHost.net) > - Inbox (MyOtherName@MyOtherHost.net) > - netscape.public.mozilla.seamonkey > + MyName@MyHost.net > - Inbox > - Templates Outlook handles this (for comparison): 1) When a folder is part of the primary personal folders account only the Folder Name is displayed ("Inbox", "For Follow Up", and "Unread Mail" in screenshot). Thunderbird could do the same thing with folders in the "Local Folders" account. 2) When a folder is in some other account, the Folder name is displayed followed by "in [Account Name]" ("New in RSS Feeds" in screenshot -- "New" is a Search Folder name and "RSS Feeds" is the Personal Folders account name). I also wanted to suggest that Favorite Folders support drag and drop. (In reply to comment #5) > Perhaps a *tooltip* with the *full path* would help: > > [ MyName@MyHost.net / Work Stuff / Downloads ] > [ MyName@MyHost.net / Home Stuff / Downloads ] I think such a tool-tip is an great suggestion.

To all developers of this new feature: Please avoid using "Favorite" when this feature will be implemented. Please don't import too many MS/IE only terminology to Mozilla family. There is another reason why I hate "Favorite(s)". - Japanese translation of "Favorite(s)" is stupid on Japanese MS Win and IE :-) Simple "Selected folders" is far better for me than "Favorite folders" as a partner of "All folders".

(In reply to comment #8) > - Japanese translation of "Favorite(s)" is stupid on Japanese MS Win and IE To be consistent with firefox, how about "Bookmarked Folders"? The workflow / UI could be like this: 1. Right-click (or File / New / ...) "New Bookmarked Folders" 2. +----------------------------------------+ | Add <foldername> to Bookmarked Folders | <-- Dropdown to select other? | [ ] include subfolders | <-- Default: deselected | Name: [ ] | <-- Defaults to <foldername> | [[ OK ]] [Cancel ] | +----------------------------------------+ 3. +------------------------------+ | Name | | -----------------------------| | Bookmarked Folders | <-- click collapses/opens BF section | -----------------------------| | o Inbox (<account1>) (x) | <- "o" = folder's icon, "(x)" = unread | o Inbox (<account2>) (y) | | o Project 1 | <-- from Local Folders | o Invoices | <-- Subfolders possible? Stays with parent. | o Project 2 | | o Planet Mozilla (RSS Feeds) | | o Recent Messages | <-- Search folder | o n.m.thunderbird (z) | |------------------------------| | All Mail folders | <-- click collapses/opens section |------------------------------| | o <account1> | | o Inbox | | o Templates | | o ... | | o <account1> | | o ... | | o RSS Feeds | | o ... | | o Local Folders | | o ... | | o news.mozilla.org | | o ... | +------------------------------+ 4. D&D of Bookmarked Folders would be great. :-) 5. Right-click on any Bookmarked Folder allows to "Remove from Bookmarked Folders List". How are Bookmarked Folders updated? In real time (as other accounts are updated)? By clicking on "Get new messages" button?

Just adding a couple of comments here.. I think having the subfolder implementation in the favorites/bookmark folders/whateveryoucallit will just make the things less useful.. Oh, how about 'shortcuts' as a name for em, since that is really what they are.. The point is to make em one click affairs, NOT click on grandparent..click on parent...click on desired shortcut folder.. these new shortcuts should have all of the current folders context items and the ability to recieve message drops ( to move messages from one folder to another ) drag and drop reordering should also be implemented. Renaming should also be allowed since it is possible for a shortcut to point to a news folder and the user might not need the shortcut to read "netscape.public.mozilla.mail-news".. and forcing an abbreviation on the user is not the answer here.. I have created a less-than-ideal implementation of this as an extension.. Read about it here.. http://forums.mozillazine.org/viewtopic.php?p=1865571 Putting the entries in the folders datasource is a much better idea than what I have done, since those shortcuts would then exist in any of the folders dropdowns in the rest of the app ( like message...move... and (message context)..copy to... Just my A$0.02

taking, work in progress patch coming up in the next day or so.

this adds backend support for folders with unread, and favorite folders - there's still some cleanup work to do, but it works fairly well as is. I'll attach some front end changes for completeness sake, though I'll leave the actual UI to Scott :-)

This makes it so clicking on the name column header in the folder pane cycles between folder views (normal -> unread -> favorites). It also adds a folder pane context menu item to add/remove a folder from the favorites list, which we will probably want to keep.

*** Bug 318103 has been marked as a duplicate of this bug. ***

This cleans up the last patch, gets rid of unused overrides, and fixes drag drop to work in folder views. I think this is ready to checkin, so we can add a front end and shake out the remaining issues. I haven't figured out how to implement recently used yet but I'll work on that after I drive some other patches in.

(In reply to comment #10) > I think having the subfolder implementation in the favorites/bookmark > folders/whateveryoucallit will just make the things less useful.. The user doesn't *have* to use it. In fact "[ ] include subfolders" should be *off* by default. However, there will likely be cases where users need access to an entire subtree (e.g., a current largish project). (In reply to comment #13) > This makes it so clicking on the name column header in the folder pane cycles > between folder views (normal -> unread -> favorites). Does this mean that while in "favorites" view, the user can't see his other folders? That would be unfortunate, at least for when the user wants to drag/drop a message from a favorite folder (Inbox) to some non-favorite folder (Local Folders / Project X / Invoices). If so, I liked my sugggestion in comment #9 step 3 better.

Comment on attachment 204560 [details] [diff] [review] backend work what about changes to mailnews\build\nsMailModule.cpp?

the changes to mailnews\build\nsMailModule.cpp are in the patch (and in my tree, or nothing would work :-) )

this patch makes it so we set the mru time of a folder when the folder is opened, a message is copied into it, or its new flag is set. I put the MRUTime string in a central place as well.

whenever you delete a folder, I was blowing away panacea.dat, but that loses the mru time. So I've changed it so we remove the element from the folder cache that corresponds to the deleted folder, instead of blowing the whole thing away.

(In reply to comment #21) > front end work including mru view. Screenshot?

updated front end patch so I can save off some of my work. Still a work in progress. Most of the changes are to the default folder pane header view so David won't notice much of a difference from his original patch. :) Lots of context menu work including some cleanup, adding a menuitem to the Edit menu for adding a folder as a favorite folder.

backend work landed on the 1.8.1 branch

The front end is far enough along that it's time to let people start using this feature. I'm planning on doing a cross-commit on this patch so we see the UI on the trunk and the branch. There are a lot of little things going on in this patch. Here are some of the highlights: 1) New menu item under View called Folders with the following options: All Unread Favorites Recent Based on the current folder pane view, the appropriate option will have be checked. This menu item is hidden in the stand alone message window. 2) The Edit menu has a new menu item above folder properties called "Favorite Folder". This menuitem toggles the favorite folder property for the selected folder in the folder pane. You should see a check box next to the menu item. 3) The sidebar header right above the folder pane is now a toolbar button, hovering over the header text should show a hover border state. Clicking the button cycles through the folder views. The text of the button changes based on the folder view: All Folders, Unread Folders, Favorite Folders, Recent Folders. 4) The folder pane context menu has a new menu item right above the properties menu item called Favorite Folder which has a check next to it when the folder is a favorite. The entire context menu has undergone some simplification and cleanup as well. 5) The folder pane view setting is persisted across sessions. We store the folder view in a pref and restore the view on startup based on the value of the pref. 6) I added some 'smart code' to generically figure out when to show/hide menu separators from our context menus and then changed the message and folder pane context menus to use this new routine instead of trying to hand check if various menu items were visible before showing/hiding a separator. 7) loadFolderView(aNewFolderView) in msgMail3PaneWindow.js is the core routine that changes the folder pane view.

I would point out that, this patch doesn't mean we are done with the front end work. I'm not happy with the toolbarbutton CSS for the sidebar header and I'd like to tie in a menu popup (in addition to the current cycler) when you right click on the sidebar header. I'm sure more things will come up. But it's a good start in exposing this new feature so we can start collecting feedback.

the front end has now landed on the branch as well.

Pretty neat. So far, appears to work as described -- altho, like Grouping, I expect I won't use it much in the long run. (In reply to comment #26) > 2) The Edit menu has a new menu item above folder properties called "Favorite > Folder". This menuitem toggles the favorite folder property for the selected > folder in the folder pane. You should see a check box next to the menu item. A peeve of mine regarding menus is when top-level menu items disappear based on context, as the 'Favorite Folder' item does when an account is selected. (See also the Message menu's Watch/Ignore items when a non-News message is selected.) I think overall it would be cleaner if the "Favorite" setting were a checkbox on the Properties dialog, along with a special icon or text styling for the folder if it's a favorite. (Of course, those icons are pretty crowded already, but that problem could be left up to the theme designers.) > 3) The sidebar header right above the folder pane is now a toolbar button, > hovering over the header text should show a hover border state. Clicking the > button cycles through the folder views. This button activates on a right-click, which maybe it shouldn't.

*** Bug 216909 has been marked as a duplicate of this bug. ***

Using 1.8_Branch build 20060216, folder pane shows the new header only if the expanded columns (Tools > Options... > Advanced > General) are NOT activated.

duh, no wonder it wasn't working for Seth - Seth checked and that logic was right in the other places, just not for the imap folder case...

actually, the local mail folder code had the same bug, and the imap folder code had a similar bug. Thx for pointing these out, Seth.

(In reply to comment #10) > Just adding a couple of comments here.. > > I think having the subfolder implementation in the favorites/bookmark > folders/whateveryoucallit will just make the things less useful.. > > Oh, how about 'shortcuts' as a name for em, since that is really what they > are.. > > The point is to make em one click affairs, NOT click on grandparent..click on > parent...click on desired shortcut folder.. > > these new shortcuts should have all of the current folders context items and > the ability to recieve message drops ( to move messages from one folder to > another ) > drag and drop reordering should also be implemented. > > Renaming should also be allowed since it is possible for a shortcut to point to > a news folder and the user might not need the shortcut to read > "netscape.public.mozilla.mail-news".. and forcing an abbreviation on the user > is not the answer here.. > > I have created a less-than-ideal implementation of this as an extension.. Read > about it here.. http://forums.mozillazine.org/viewtopic.php?p=1865571 > > Putting the entries in the folders datasource is a much better idea than what I > have done, since those shortcuts would then exist in any of the folders > dropdowns in the rest of the app ( like message...move... and (message > context)..copy to... > > Just my A$0.02 Sorry- coming in late to the discussion. I just wanted to say that I use Outlook at work find that the Favorites/Shortcuts is a great, virtually indispendible feature. In fact, I'm the one who bugged Frank to create his extension (much thanks!). If the final implementation worked like his extension it would be great - it does everything I use this feature for in Outlook. David

Why favorite folders as it is much easier to add a searchbox above the folder pane (as above the message pane)and insert the folder you want to view in this box (with autocomplete)?

(In reply to comment #35) > Why favorite folders as it is much easier to add a searchbox... Because the favorites (a) point to specific and predefined locations, and the user doesn't have to think of the remembered names of (sub)folders, and (b) the user might want to copy messages from one favorite folder (e.g., Inbox) to another favorite folder (e.g., Project X Invoices). This would not be possible with a searchbox filter (because either the "inbox" or "Project X Invoices" would be hidden). PS. I think this "search" (and "tag") everything trend has gone too far. Favorites folders (and bookmarks) have specific value too (IMO more than tags/searches). Having said that, I really miss a searchbox-filter in the Password Manager (much more so in Firefox).

Instead of having to *cycle* through all the views (all > Unread > Favorites > Recent > All) (feels like walking through a dark room: you don't know what is coming next), I would prefer if the views could be selected via a *dropdown* list: +------------------------------+ | [ Favorite Folders \/]| <-- Whole width clickable | | All Folders || | o| Favorite Folders || <-- After "All Folders" | o| Unread Folders || <-- Unread&Recent=grouped (auto-generated) | o| Recent Folders || | o+--------------------------+| | o Inbox (<account1>) (x) | | o Inbox (<account2>) (y) | | o Project 1 |

(In reply to comment #37) > Instead of having to *cycle* through all the views (all > Unread > Favorites > > Recent > All) (feels like walking through a dark room: you don't know what is > coming next), I would prefer if the views could be selected via a *dropdown* > list: At least some sort of customization would be nice. Sort of 'Folders to cycle through' like you can do with 'Expanded columns in the folder pane'.

I agree with comment 37 that the cycle-thru model is less than ideal, and I also don't think the little left/right arrow icon is particularly clear. Using a "menulist-compact"-class dropdown would be one possibility. This is the sort of dropdown used in the compose window to change the To/CC/BCC labels in the addressing widget. The appearance of those buttons that I have (with a modified userChrome.css -- see bug 301465) makes them look relatively flat. The main problem with having a dropdown of any sort is that currently, dropdowns always require focus in order to work, and putting focus in a toolbar is always a source of problems (as can be seen in all the fiddling trying to get QuickSearch to behave). Since the folder-view dropdown (and, for that matter, the mail-view dropdown) are both replicated in the menus, these could be replaced by a new mouse-only dropdown that doesn't grab focus (just as toolbuttons and the current widgets on the folder-view header don't).

Not sure if it is correct to add these bugs are blockers for this bug, please remove if incorrect but these are issues I think need to be resolved before this can be marked as fixed.

hi, (my english is bad ) nobody needs several - trash, junk and inbox folders solution: for junk and trashfolder set a general folder for all accounts slution for inboxfolder: set a virtuall folder for all accounts or minimum one virtuall folder for all email+imap accounts and separate one for news and rss please set in the flolderpane the adressbook icon and open the adressbook in the main window

Looking at the current implentation I'd like to have more options than the 4 views. If I could create more user-defined Folder Views this would be a much better feature. For instance, I'd like to have a view of Favorite Folders with Unread, a folder view of all news folders and a folder view of all feeds folders. Having a folder view for each account would also be neat (that's in addition to an "All accounts" view of course).

marking fixed - we'll open new bugs for remaining issues.

*** Bug 162566 has been marked as a duplicate of this bug. ***

For those interested, I've created an extension that adds a new folders view above the standard view: http://legege.com/en/mozilla/afview

(In reply to comment #10) > Just adding a couple of comments here.. > > I think having the subfolder implementation in the favorites/bookmark > folders/whateveryoucallit will just make the things less useful.. > [...] > The point is to make em one click affairs, NOT click on grandparent..click on > parent...click on desired shortcut folder.. > I agree that the implementation ought to be as transparent to the user as possible, but if the favorites don't include some form of folder heirarchy, it might still be useful if they included at least to which account the folder belongs. Why? Let me give an example: we use IMAP, and users need to sometimes archive data from the server-side IMAP store to a folder tree in the Local Folders tree. They may not archive all the data. Under IMAP, some of our users have fifty or more folders, sometimes with complex but well thought out structures. When they migrate archived data to Local Folders, they often keep the same structure and heirarchy and often the same folder names. They would like to be able to see a subset of their folders. The Favorites implementation would be a way to do this, but without SOME way of identifying to which account or heirarchy the favorite folders belong, it is difficult to know which folder in the list belongs where! Possibilities to help disambiguate: (1) have a separator in the Favorites list, for each "account" tree to which the folder belongs, or (2) have a tooltip popup that identifies "account" for a favorite folder when you hover, or (3) Show the skeleton structure of the folder heirarchy in the favorites list, or (4) OUTSIDE of the favorites mechanism, provide a way to "subscribe/unsubscribe" or "show/hide" particular folders even in POP and Local Folder account lists.