If I collapse the sidebar in the main mail/news window, there is no way to tell what the current folder is, nor any way to switch between folders. Both of these functions were done using the same widget in 4.X.

I expect we'll display the folder name in the window's title bar, which is covered in bug 13807. But that doesn't really solve being able to select a different folder when the folder pane is collapsed. I don't think we have a solution proposed for that. Jennifer?

The "Location Toolbar" should take care of this. Please see Main Mail spec http://gooey/client/5.0/specs/mail/messenger/messenger.html#Location

Oh, sure enough. I thought we'd dropped that. I must be confused. Since I can't find a feature bug for the location toolbar, I'll use this bug for that purpose. Reassigning to putterman

I think this should include the server or account name too, so you can easily distinguish which inbox you're looking at. I know that it is in the window title, but I can't seem to train myself to look there, probably because most programs don't change the window title depending on a selection inside the window. Anyway, once you select a message for display in the message pane, the window title changes to the message, so there is still no context clue. Other popular mail programs make this info very obvious.

Could we append the account name to the folder name? Inbox on <accountname>

P4 per m/n staff mtg today

[FEATURE] bugs past M16 are OUT for this release. Marking M20. If you disagree with this action, please help me explain it to the PDT.

This means we'll have no location bar, or any other means of switching folders other than the sidebar, right? That will either greatly increase the minimum width monitor for reading mail, or require opening and closing the sidebar whenever switching folders. I guess that reading messages in a separate window would suffice, but none of the navigational commands for that are currently working either.

Trudelle - no navigation items will work in the standalone window for this release (subject of another bug / PDT meetings).

Peter - you can also try the alternate three pane mode where: 1. there is no sidebar, 2. there is a folder pane, but it only takes up the room of the thread pane (ie. Message pane will expand the width of the window).

Thanks, but I have too many folders for that to be practical. It should suffice for many users though, probably most of them.

This is a feature I like in Communicator. Using a 800x600 screen I need nearly the whole width for a text message. I also need a wide Subject column because threading uses up much space in Communicator. Once you've added the Flag, Size, Status, Date, Sender, Mark and Thread columns I don't have room for folders.

Future milestone. adding helpwanted keyword

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

adding some keywords. This would be a nice feature for Mozilla 1.0 and the next Netscape release :)

marking nsbeta1-. I agree that there are people who would like this, but I think we still cover the majority of users with the current UI.

This is already part of the current interface, or at least it was until NS6 came out. All versions of NS4 had this feature. The sidebar is most unsuitable for a portable with an 800x600 screen and it's completly annoying to keep opening and closing it all the time.

Although not exactly what the bug was asking for, this is a good workaround for this. Perhaps we should open another bug. This is a pretty good idea and will allow the folder pane to be collapsed. In addition it would provide an easy keyboard/menu driven way to access folders for accessibility. I haven't looked at the patch, so this may not be an issue, but we just need to make sure that everything still works. I think folder selection drives a lot of the ui.

Basically the patch enhances the code used to select the start folder. OT: I added HasUnreadMessages to indicate the folders with unread messages. How do I refresh the flags when the menu opens? Currently if I read a group it stays bold in the menu :-(

just coming up to speed on this... you'll need to have a listener to get notified when the unread status changes. sort of like how the folder pane has a listener when the unread message count changes. we could work on landing this first, and then adding the listener. I'd like to review and test your patch, but I won't be able to get to it today.

listeners, or oncreate events. can you use 2/4 spaces instead of more/tabs? and please aim for 80 column limit on all text files, it makes xul much easier to read. <rule iscontainer="true" isempty="false"> <menu uri="..." ...> <menuitem uri="..." .../> this part of the rdf worries me, but i'm not an expert.

Should include not just Mail folders, but Newsgroups as well. Should not have to dig into menu, or switch to 3 pane mode (opening sidebar) unless you have the screen area to do so and desire to do that way.

> can you use 2/4 spaces instead of more/tabs? and please aim for 80 column > limit on all text files, it makes xul much easier to read. Any tabs, long lines and uri="..." were probably copied from existing code. > Should include not just Mail folders, but Newsgroups as well. Should not have > to dig into menu, or switch to 3 pane mode (opening sidebar) unless you have > the screen area to do so and desire to do that way. You have to dig into the menu because menus don't support indents so I don't think flattening the menu would work. Newsgroups are included. > you'll need to have a listener to get notified when the unread status changes. But not when new folders are created? Sigh...

>> you'll need to have a listener to get notified when the unread status changes. > But not when new folders are created? Sigh... actually, this should just work. you're using XUL templates, so they'll get built based on what's in the account manager and folder datasources. you wrote: > I added HasUnreadMessages to indicate the folders with unread messages. > How do I refresh the flags when the menu opens? Currently if I read a group it > stays bold in the menu :-( I would have thought this would have worked. does your menu pick up changes in folder names? I'll try out your patch and see for myself.

I was using an older version of Mozilla; folder changes get picked up OK in 2001012904 for instance. It's difficult to test anything else because once you switch a skin all the icons switch back to folders :-(

that switching skins bug is a known problem. when my build is done, I'll try out your patch and report back.

As far as boldness of folders with unread messages, I don't see any skin changes in the patch. Perhaps you need a style rule for this?

True. Example of CSS that you could add to messenger.css: .folderMenuItem[IsServer="true"], .folderMenuItem[HasUnreadMessages="true"] { font-weight : bold; }

In reading Comments about Location Tool bar. Location Bar on Communicator has just two items a button with name of current folder (inbox or newsgroup). At opposite end show number of total messages and number of unread messages. The button you click on and you have a Drop-Down or Pop-up Menu (ever how one describes it) with a listing of all folders (names of Mail box, Unsent, Templates, Drafts, and so on, then each newsgroup. Just click on button, move mouse up or down to highlight where you want to go and and release the button. There is no need for tabs.

This CSS does work with my patch on recent builds of Mozilla: .folderMenuItem { font-weight : normal; } .folderMenuItem[IsServer="true"], .folderMenuItem[HasUnreadMessages="true"] { font-weight : bold; } Although skin authors might not want this in their skin.

Spoke too soon, sorry.

Looks as if menu templates are normally only built once. e.g. create a folder, look for it in message/copy menu. create a sibling folder, look for it in message/copy menu - fails. look for it in message/move menu - ok.

Does the window list [tasks?] use the same template system? because it is usually rebuilt...

Notes about the location toolbar as attached: 1. I had to change the SelectFolder function (because of duplicate ids?) 2. Communicator's location toolbar has total and unread message counts. I have attempted to duplicate these but I ran into some problems: a. The order was different in Communicator than in Mozilla's status bar. b. you might want to remove the counts from the status bar. c. They don't look good without any css in the skin. d. They might need extra localising. e. They would affect messenger.xul and mail3PaneWindowVertLayout.xul Let me know how you would like this handled. 3. I included the extra image because this is how it looked in Communicator. This allows the skin to decide on inside or outside image placement. 4. Some example css (this belongs in messenger.css): #locationIcon { margin: 3px; } #locationFolders { margin: 2px; list-style-image: none; -moz-user-focus: none; } .folderMenuItem { font-weight: normal; } .folderMenuItem[IsServer="true"], .folderMenuItem[NewMessages="true"], .folderMenuItem[HasUnreadMessages="true"] { font-weight: bold; }

One further caveat: changes to the current folder (e.g. rename, new messages) are not reflected in the menulist itself. There may well be some way of doing this in RDF but someone else will have to fix it, sorry.

BTW (sorry for the SPAM), any RDF experts want to flatten the menulist?

Another apology: css should have -moz-user-focus: ignore; not none.

sorry for the delay. I haven't had time to get to this yet. can you provide a complete, update to date patch, with all the modifications you've proposed since the original patch? when I get some time, I can check it out. (or perhaps racham can)

So you want both the Go menu and the Location toolbar in one patch?

if it is all one feature, then yes, please, all one patch. if you can break it up into two feature, please do so. it is easier to land smaller patches. (just log a new bug and attach the second patch to it.)

The Go menu was really an interim alternative to the Location bar. Unless you really want it I won't merge it in. The CSS is not mandatory for the location bar but makes it look a little nicer.

nicer is better, so let's include that. please attach the patch you want me to work with. looking back at the comments, you had some issues. If there are still issues, let me know with a comment after you attach the patch. thanks for going the extra mile with me on this one, neil.

These patches don't take into account the AccountCentral changes. Hopefully I can get something done this week.

neil, hold off on this. mscott is about to land the mailnews performance branch, which will require you to do a whole new patch. after that landing, we'll work on landing this patch. I apologize for all the delays.

I've been looking into a flat menulist. I've run into a problem. When you finish reading a group, it loses its boldness. This changes the width of the text. If it used to be the widest text, the whole menulist shrinks!

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

CCing Håkan Waara for general comments.

I don't like the idea of implementing Yet Another tree. I think you should use the outliner instead.

Reversing database corruption caused by bug 95857 and bug 95798. Pay no attention to the man behind the curtain.

Whenever I put an outliner in a menulist it crashes :-(

Sorry for leaving a dump command in that last patch :-(

Any chance of a review on this patch before it bitrots again?

this was just brought up again as missing in n.p.m.mail-news today. Any chance for reviews, even though it has been futured?

There's a feature freeze going on in the mailnews module, until 0.9.9. See npm.mail-news for more info.

For those trying to figure out what a location Tool Bar for mail and news looks like Go to: <snews://secnews.netscape.com/netscape.test> look for the subject line Location Toolbar. Notice the drop down menu when button clicked on just scroll down release button when desired item is selected. As I am not a programmer I don't know the complexities of programming it but it Looks simple. as for the messages totals I don't pay attention to those anyway. I'm just interested in the button with the drop down menu. The item is actually a little over 100% so you can read the titles. Now show this on a 14-15" monitor see what I'm up against.

I've developed an XBL widget for the menupopup which will allow me to reuse functionality for the other folder pickers i.e. File, Sent/Drafts/Templates, New, Rename, Search, Filter folder pickers. If any mailnews reviewers have the time just let me know and I'll run up a new patch.

This 'feature' should allow people to keep the folder pane closed, which would save screen real estate, RAM and lots of time when opening new windows. That's performance and usability work, two of the themes of mozilla1.0.

I don't like the placement of Quick Search at all, so merging this with Quick Search in a toolbar (as showed on images in npm.mail-news newsgroup) would be a big win. If there will be a patch with this incorporated, I would kindly request the mailnews module owners to consider taking it for usability reasons.

The fix for this bug will also permit a single drop down for all folder pickers e.g. search, file, drafts, templates. I am waiting for the bookmarksliner to land to see if there's a better way to reuse my code. It is possible that this bug will be fixed by creating a third alternative layout thus integrating into bug 105542.

I don't know how much RAM it would save because we still have to load the internal folder list. It would save open window time but only for the minority of users who will use it since we'd still ship with the 3 pane. And, even though testing shows that not having a folder pane improves performance, some of the time saved in those tests is associated with building a folder tree which would still have to happen in this case.

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

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

My five month old bug 109649 just got duped to this. Why is keyword 4xp missing from this bug?

I notice in description above that in ()'s only "menu of mail folders". It should apply to newsgroups as well and should read "menu of mail folders & newsgroups.

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

nominating for nsbeta1 based on usability test showing that a user who closes folder pane has no way to see messages in other folders.

I also saw this during jglick's UE study, so adding [ue] to status whiteboard. note, using mozilla in two pane mode will be problematic until we fix some other bugs. query for all the bugs with [twopane] in the status whiteboard.

Discussed in mail news bug meeting. Decided to minus this bug.

Two Pane Mail Location Toolbar only enabled: http://www.mozilla.org/mailnews/specs/threepane/images/Mail2.gif Two Pane Mail with Location Toolbar and Quick Search enabled: http://www.mozilla.org/mailnews/specs/threepane/images/Mail2b.gif Also see related Bug 146543.

This patch only adds the location toolbar and the Go menu folders; it does not display the total or unread counts in the location toolbar, nor does it contain any skin and therefore I did not attempt to move the search box.

So if the Location toolbar is turned on and the Quick Search bar is turned on, there are two toolbars? Do you a screenshot you can post?

My screenshot has something that resembles the search bar in the location bar :-( I'll see if I can fix that over the weekend.

Are there test cases for various combinations of the location toolbar and the functionality associated with it?

This patch puts the search bar to the right of the location folders (as per the screen) if both are visible, otherwise the search bar is in its current location.

Comment on attachment 84972 [details] [diff] [review] Full up-to-date patch Um, in mailWindowOverlay.xul, <hbox context="folderPaneContext"> should (of course) be <hbox align="center" context="folderPaneContext">

With the Folder pane closed, these context menu items become inaccessible. Can't we place them on a submenu someplace? If they're not important, they shouldn't be on the context menu in the first place: - Compact *this* folder - Copy folder location

guanxi, my patch adds them to the location icon/menulist.

I remove nsbeta1- keyword - it was for MachV.

Now I add 'nsbeta1' keyword for Buffy. Sorry, it's faster to edit multiple bugs at once than manually go to each and remove minus.

so i'm a bit confused? does this patch do the trick or not? if so, why hasn't it made it into a distribution?

Sorry, I am unclear on the progress of this bug fix. Is there a fix to add a Location Toolbar like feature? Will it make it to a release?

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

A couple quick things that hopefully don't bear too close a resemblance to bugspam: 1. Patch and review keywords apparently need to be up-dated. According to <http://bugzilla.mozilla.org/describekeywords.cgi>, '*Do not use this keyword. Please use the patch manager instead.*' Dunno. . . . 2. The flag, currently off, indicates 1.3a (even tho' the bug is futured). Since a lot of work seems to be going in to Mail/News of late, is there any way that this could get in to the 1.3 cycle? If not, could there be a clearer indication of the status of this bug and the available patch (see, /e.g./, comments #90 and #91)? The reason for trying to draw a modicum of attention back to this bug is that for some people the absence of this seems to be a serious usablity (if not accessibility) issue, so it would be nice to see it go in. 'Sides, then Phillip would have to another hobby horse. :-)

If it was to go in. who knows I might actually switch permanentlt ot Moz/N7. Whereas now without it I remain with Communicator until it actually croaks.

same for me. that was the only reason i ever added myself to the e-mails for this, so that i will know exactly when it is time for me to convert.

This is a serious usability issue for not only myself but several folks I work with. If it were included in the next release I could finally upgrade from NS4.8.

"The reason for trying to draw a modicum of attention back to this bug is that for some people the absence of this seems to be a serious usablity (if not accessibility) issue, so it would be nice to see it go in. 'Sides, then Phillip would have to another hobby horse. :-)" Yes indeed I could. Would be great if it went in. This is the major killer for me to use Moz/N7 as my email client. There are couple of minor issues left but I can work around those. This one I can't.

First to say that there is lots of people needing this feature (I never cared but my users do and have been asking me about it). Second - the patch from neil@parkwaycc.co.uk doesn't apply cleanly anymore. I have managed to fix it up enough to make it work on 1.2.1 (involved minor work and removing of a couple of pieces of his patch that seemed not to help). You can find that patch and a patched version of mozilla-1.2.1-talkback for win32 on http://www.math.princeton.edu/~plazonic/mozilla/. It seems to work fine (thanks Neil!) and it only adds Location Toolbar. I'll also try to add the patch as an attachment to this bug.

re-assign to neil. I think he plans on doing this for 1.4 or 1.5

the spec can be found here: http://www.mozilla.org/mailnews/specs/threepane/

Need new QA assignment/contact to test this feature. Olgam is no longer working on this project. For now, reassign to nobody@mozilla.org Anyone on the open source side want to pick this up for testing and creating test cases?

I haven't been able to match picture A/1/c in the spec (A/1/d is OK)

>I haven't been able to match picture A/1/c in the spec (A/1/d is OK) The spec was written before the Quick Search bar View menu item was added. A/1/d. Do you have the Folder menu, the View menu and the Quick Search field all on the same toolbar? Its it too tight a fit? Its it too much to show to user on one toolbar (very crowded/busy looking)? One solution would be to always have the Location toolbar as a separate toolbar. So A/1/c would always be the case for the Location toolbar. So, if the user had the Location toolbar and the Search toolbar turned on, they would appear as two separate toolbars. Location toolbar with Search toolbar below it. Since they will be two separate menu items, "View: Show/Hide: Search Bar", "View: Show/Hide: Location Bar", two separate toolbars might be the way to go. Thoughts?

Note, this is using my custom theme which tends to pack widgets more closely.

Neil, that screen shot looks like good work!

Looks good Neil. A few comments/concerns. 1. How would this appear to users with the default Modern theme? Is it too cramped? What if a View or a Folder has a long name? What about larger resolutions/fonts? 2. There still needs to be a way to turn it on/off via the View menu. "View: Show/Hide: Location toolbar" isn't correct if it isn't a separate toolbar, but just a widget on the Search toolbar. 3. If the user decides to hide the Search Toolbar, the Location/Folder widget becomes not available either, since its just a widget on the Search Toolbar?

this part of the spec was written before the QS toolbar. i think we want a separate toolbar, (with the unread and total counts) like in http://www.mozilla.org/mailnews/specs/threepane/images/Mail2.gif This also allows the user to do "View | Show/Hide | Search Bar" and "View | Show/Hide | Location Bar" independently. the cost of this is vertical space. the long term solution is configurable toolbars, but we're a while from actually having that in Seamonkey (Phoenix has it)

The way I currently have it rigged up is that the search and location toolbars share space, so you can turn them on and off separately. Unfortunately this makes the location toolbar take up an unreasonable amount of space if you turn off the search bar, it doesn't move the message counts (because the labels differ).

Neil, When you pull down your location bar, does it have a scroll bar on the right? Josko's patched version puts a scroll bar on the right even if the drop down menu doesnt reach the bottom of the mailreader window. Personally, Id like it to act as closely like NS 4.8 if possible. Thanks for revisiting this bug! Jason

Thanks, I see your point, it isn't calculating the height properly.

>The way I currently have it rigged up is that the search and location toolbars >share space, so you can turn them on and off separately. Are you adding a "View: Show/Hide: Location Toolbar" menu item? "Location Toolbar" probably isn't a correct term if its not a separate 'toolbar' and just a folder selection widget on the Search Toolbar. So it would have to be something like "View: Show/Hide: Folder Selector" (needs work). Can a user have the Folder Selection widget and the Folder Pane visible at the same time? If so, they need to match each other at all times. Hence, if they change folders via the folder pane the Folder Selection widget would need to change also, and vice versa. Or, another option would be to only allow one or the other, so we'd add a "View: Show/Hide: Folder Pane" menu item. When its On, the Folder Selection widget is not visible. When "View: Show/Hide: Folder Pane" menu item is turned off, the Folder Selection Widget appears. In this case, a "View: Show/Hide: Folder Selection widget" type menu item would not be necessary.

Yes, I can rename the location toolbar to folder selector. The selector keeps up with all folder changes, e.g. next unread navigation. The selector updates the folder pane in the same way as next unread does. As for the scrolling issue, try this change to mailWidgets.xml; after var height = view.rowCount * this.tree.treeBoxObject.rowHeight; add var body = this.tree.treeBoxObject.treeBody; height += this.boxObject.height - body.boxObject.height;

>Yes, I can rename the location toolbar to folder selector. Robin, what would you suggest calling this item? "View: Show/Hide: Folder Selector", "View: Show/Hide: Folder Menu", "View: Show/Hide: Location Toolbar" (not very accurate). >The selector keeps up with all folder changes, e.g. next unread navigation. >The selector updates the folder pane in the same way as next unread does. Great. An vice versa as well? If I change the folder via the Folder Selector, the Folder Pane changes appropriately as well? With this being implemented, we probably want a "View: Show/Hide: Folder Pane" menu item added.

>>The selector keeps up with all folder changes, e.g. next unread navigation. >>The selector updates the folder pane in the same way as next unread does. > >Great. An vice versa as well? If I change the folder via the Folder Selector, >the Folder Pane changes appropriately as well? That's what I was trying to say... >With this being implemented, we probably want a "View: Show/Hide: Folder Pane" >menu item added. I seem to remember that there already is a bug filed for this...

Re: comment 113 "View: Show/Hide: Folder Menu" is fine with me.

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

still missing in 1.4a (2003040105)

scott is looking to take something like this for thunderbird, so we'll try to coordinate during 1.5 to make this happen.

Any news on the status of this one?

Tbird is going to Release 0.2 and we still are not seeing this enhancment getting into the code tree. Even with a 17 inch monitor and 1024x768 res I feel the loss of screen real estate a serious regression form NC4.8 feature set. I currently configure TB to option 2 of folder/header panes over wide messsage pane. It's the least loss of screen space while the Sky Pilot Classic theme is active with it's grippy buttons and the QuickTools Grippy extension installed. Migration learning curve is a useability issue. Surprising the quantity of OE users I have learned have NC4.x as alternate/backup application. Lets land this sucker and get it debugged.

Just another yes please - this is actually one of a class of problems that I hadn't noticed because of my high res monitor that my dad immediatly noticed on his 1024x768 display (especially because he likes large fonts).

Enough with the advocacy comments. Unless you're directly involved with designing, coding, or testing this feature, please refrain from commenting in this bug.

i was thinking that an alternative way of doing this that would not have to add more space on a toolbar, and possibly would not need to make an option to turn it on and off would be to make a folder tree like the bookmarks folder tree, when you click on the go menu. for example go next previous account 1 inbox drafts templates sent junk trash other folders other folder local folders folders under local folders mail start page

there's a patch, please stop thinking about alternatives. there are many reasons to do this the way neil is doing it.

I've come across this extension, for Thunderbird at least. I haven't tried it myself. http://www.supportware.net/mozilla/ Look under "Netscape 4.7 Look hack v0.1" Screenshot: http://www.supportware.net/mozilla/NC4.7lookalike.jpg

I even had to work around an obscure XBL crash or 100% CPU bug.

Comment on attachment 191912 [details] [diff] [review] Substantially updated for bitrot >Index: mailnews/base/resources/content/mail3PaneWindowVertLayout.xul >=================================================================== >+ <toolbar id="msgToolbar"/> To make the >+ <toolbar id="msgLocationToolbar"/> appear below the msgToolbar, I suppose? >Index: mailnews/base/resources/content/msgMail3PaneWindow.js >=================================================================== >@@ -898,6 +900,8 @@ function InitializeDataSources() > //Setup common mailwindow stuff. > AddDataSources(); > >+ SetupMoveCopyMenus('goMenu', accountManagerDataSource, folderDataSource); >+ > //To threadpane move context menu > SetupMoveCopyMenus('threadPaneContext-moveMenu', accountManagerDataSource, folderDataSource); Wrong indentation, because the other lines have tabs. :-/ >+function OnLocationToolbarAttrModified(event) >+{ >+ if (!/collapsed/.test(event.attrName)) >+ return; Why not a simple |if (event.attrName != "collapsed")|? (And wrt the indentation: it's pretty broken, taken the file as a whole. About half of the file (I didn't count lines) adheres to the 4 characters statet in the first line, but the rest already uses the now standard 2 chars. So I'd say it'd better to correct/delete the top line and use the 2 indentation for new stuff.) >Index: mailnews/base/resources/locale/en-US/messenger.dtd >=================================================================== > <!ENTITY showSearchToolbarCmd.label "Search Bar"> > <!ENTITY showSearchToolbarCmd.accesskey "e"> > >-<!ENTITY showLocationToolbarCmd.label ".Location Toolbar"> >+<!ENTITY showLocationToolbarCmd.label "Location Toolbar"> > <!ENTITY showLocationToolbarCmd.accesskey "L"> Indentation? Some more nits: - With the LT activated at startup and no folder selected (eg. a new profile with just Local folders and a news account), the dropdown is empty. This leads to various JS error when eg. opening it: JavaScript error: , line 0: uncaught exception: [Exception... "Component returned failure code: 0x80070057 (NS_ERROR_ILLEGAL_VALUE) [nsIRDFService.GetResource]" nsresult: "0x80070057 (NS_ERROR_ILLEGAL_VALUE)" location: "JS frame :: chrome://messenger/content/mailWidgets.xml :: setInitialSelection :: line 1841" data: no] Furthermore, the dropdownlist is far too long in this case. - Classic shows a doubled border around the location dropdown's menuitems. - I know NS 4.x had the folder icon in front of the dropdown, too, but I wonder why. This looks very strange, especially with the missing distance to the grippy. ;-) How about showing the folder icon inside the menulist instead? - Deep folder hierarchies (>level 10 for me) lead to virtually empty lines in the location dropdown. This does happen in the folder tree, too, but usually not that early. - The folder popup hierarchy in the Go menu has the container item label doubled in its child popup, unlike all our other such popup hierarchies: folder1 folder2 -> folder2 folder3 ------- folder4 -> folder4 folder5 ------- item6 - The search bar inside the location bar is a nice idea, but it looks quite importunate wrt the location dropdown. Maybe we should right-align it? (BTW: NS 4.x had the unread/total count inside the location bar also... I'm not quite sure (yet) if this is useful... *g*)

(In reply to comment #127) >(From update of attachment 191912 [details] [diff] [review]) >>Index: mailnews/base/resources/content/mail3PaneWindowVertLayout.xul >>=================================================================== >>+ <toolbar id="msgToolbar"/> >To make the >>+ <toolbar id="msgLocationToolbar"/> >appear below the msgToolbar, I suppose? Correct. >>+ SetupMoveCopyMenus('goMenu', accountManagerDataSource, folderDataSource); >Wrong indentation, because the other lines have tabs. :-/ You then go on to request two spaces... >>+function OnLocationToolbarAttrModified(event) >>+{ >>+ if (!/collapsed/.test(event.attrName)) >>+ return; >Why not a simple |if (event.attrName != "collapsed")|? In case someone clicks on the grippy (which sets moz_collapsed). >I know NS 4.x had the folder icon in front of the dropdown, too, but I wonder >why. This looks very strange, especially with the missing distance to the >grippy. ;-) Sorry, I don't understand that comment. >How about showing the folder icon inside the menulist instead? Would you mind if I made it optional so that themes could choose? >Deep folder hierarchies (>level 10 for me) lead to virtually empty lines in >the location dropdown. This does happen in the folder tree, too, but usually >not that early. Maybe I could figure out a way to make the dropdown resizable (possibly via a splitter). >The folder popup hierarchy in the Go menu has the container item label >doubled in its child popup, unlike all our other such popup hierarchies: Maybe I should forget that and a) make the dropdown focusable (it wasn't focusable in 4.x) or b) make it so the F4 key always drops it down. Otherwise I wasn't sure what text to replace the label with. Suggestions? >The search bar inside the location bar is a nice idea, but it looks quite >importunate wrt the location dropdown. Maybe we should right-align it? I'm not sure what you mean here, the search bar flexes to the available width. >(BTW: NS 4.x had the unread/total count inside the location bar also... >I'm not quite sure (yet) if this is useful... *g*) It's unfortunately not straightforward to implement :-/

> >>+ SetupMoveCopyMenus('goMenu', accountManagerDataSource, folderDataSource); > >Wrong indentation, because the other lines have tabs. :-/ > You then go on to request two spaces... Well, in general, I'd like two have two spaces. But especially in this file with different indentation all around, it should at least be consistent within a function. (The real problem here are the tabs in the other lines.) > >Why not a simple |if (event.attrName != "collapsed")|? > In case someone clicks on the grippy (which sets moz_collapsed). Ah, okay. > >I know NS 4.x had the folder icon in front of the dropdown, too, but I wonder > >why. This looks very strange, especially with the missing distance to the > >grippy. ;-) > Sorry, I don't understand that comment. In Classic, the icon before the menulist is very near to the grippy. > >How about showing the folder icon inside the menulist instead? > Would you mind if I made it optional so that themes could choose? No problem. > >Deep folder hierarchies (>level 10 for me) lead to virtually empty lines in > >the location dropdown. This does happen in the folder tree, too, but usually > >not that early. > Maybe I could figure out a way to make the dropdown resizable (possibly via a > splitter). I'm well aware that we can't catch all kinds of strange folder hierarchies. :( > >The folder popup hierarchy in the Go menu has the container item label > >doubled in its child popup, unlike all our other such popup hierarchies: > Maybe I should forget that and a) make the dropdown focusable (it wasn't > focusable in 4.x) or b) make it so the F4 key always drops it down. > Otherwise I wasn't sure what text to replace the label with. Suggestions? I quite like the idea with the Go menu, just drop the subfolder name and the separator ( = the first two items) in the submenus. The dropdown could/should be focusable anyway (just not part of the F6 cascade). > >The search bar inside the location bar is a nice idea, but it looks quite > >importunate wrt the location dropdown. Maybe we should right-align it? > I'm not sure what you mean here, the search bar flexes to the available width. It didn't for me, but I'll double check that tonight. (The clear button was at about 2/3 of my window's width which lookes really ugly.) > >(BTW: NS 4.x had the unread/total count inside the location bar also... > >I'm not quite sure (yet) if this is useful... *g*) > It's unfortunately not straightforward to implement :-/ Okay. We'd run into space problems anyway on small resolutions with both count and search in the same toolbar...

(In reply to comment #129) >In Classic, the icon before the menulist is very near to the grippy. Oops, I don't know how that happened. It's supposed to have 3px margin. Instead I gave it 0px margin !important :-/ >I quite like the idea with the Go menu, just drop the subfolder name and the >separator ( = the first two items) in the submenus. Then how would you select the parent folder? >>I'm not sure what you mean here, the search bar flexes to the available width. >It didn't for me, but I'll double check that tonight. (The clear button was at >about 2/3 of my window's width which lookes really ugly.) My fault again, it's missing a flex="1" this time.

> >I quite like the idea with the Go menu, just drop the subfolder name and the > >separator ( = the first two items) in the submenus. > Then how would you select the parent folder? Um, yeah, okay, clicking the parent just opens the child popup. The MoveTo context menu has 'file here' instead of the folder name, so maybe we can say 'open this folder' (with better wording *g*)?

>>-<!ENTITY showLocationToolbarCmd.label ".Location Toolbar"> >>+<!ENTITY showLocationToolbarCmd.label "Location Toolbar"> >Indentation? Very few entities in this file use tabs or multiple spaces, so I was just eliminating another one.

(In reply to comment #127) >- Classic shows a doubled border around the location dropdown's menuitems. -moz-appearance :-[

This should address most of your review comments. It also adds an F4 key, which might mean scrapping the Go menu changes.

Comment on attachment 194389 [details] [diff] [review] Updated for review comments > This should address most of your review comments. It does, just two nits remaining for consideration: ;-) I really think that having the icon _before_ the dropdown is plain ugly, and we don't do that anywhere else. Furthermore, showing it on the inside would show opened folder icons when opening the dropdown... Having the F4 key is nice, but the dropdown not being part of the tab order is quite confusing, given that the view dropdown directly next is. I still think it should be tabbable, too. You're our UI czar, but please give those two another thought...

The only shared file is mailWidgets.xml and the two changes a) allow F4 to close as well as open, the popup (also used in filter editor and advanced search) and b) avoid an assertion when the URI has not yet been set.

Comment on attachment 194829 [details] [diff] [review] Fixed nits hmmm, do we need to get special permission because of the shared code issue?

(In reply to comment #137) > hmmm, do we need to get special permission because of the shared code issue? I guess we need mscott (or is there someone else?) to approve as well...

Comment on attachment 194829 [details] [diff] [review] Fixed nits I concur that the changes to mailWidgets.xml should not be an issue.

Comment on attachment 194829 [details] [diff] [review] Fixed nits a=me for suite-specific parts. would be nice to have an OK from mscott/bienvenu or whever can speak for TB before it's really getting checked in.

I'll try running with this with TB

a=mscott for the mailWidgets.xml change that effects thunderbird for the branch.

Using SeaMonkey: It would be nice if the location bar could be shown automatically when the folder pane gets hidden and vice versa. I think the current behavior of manually showing/hiding the location bar from the View menu is not so convenient and useful. If the location bar gets shown/hidden automatically the extra menu entry in View -> Show/Hide could be removed, also.

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

FYI, I'm porting Neil's work here to Thunderbird as an optional toolbar button in: Bug 349767

FYI the main patch landed in CVS on 2005-09-14 although there were followups.