"Expanded Columns" in the folder pane are no longer available to select columns for display for message total count and folder size

RESOLVED FIXED in Thunderbird 38.0

Status

defect
P2
normal
RESOLVED FIXED
11 years ago
10 months ago

People

(Reporter: jrossiter, Assigned: aceman)

Tracking

(Blocks 2 bugs, {regression})

Trunk
Thunderbird 38.0
Dependency tree / graph
Bug Flags:
in-moztrap +

Thunderbird Tracking Flags

(thunderbird38 fixed)

Details

(Whiteboard: [duptome][To enable the feature: View-> Layout-> Folder Pane Columns], URL)

Attachments

(1 attachment, 8 obsolete attachments)

(Reporter)

Description

11 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b2pre) Gecko/20081113 Minefield/3.1b2pre
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b2pre) Gecko/20081113 Lightning/1.0pre Shredder/3.0b1pre

The "Show Expanded Options in the Folder Pane" (Advanced Options) is no longer functioning, starting with 11-13 nightly.

The column header configuration button is missing, and pre-configured columns disappeared upon upgrade.

Reproducible: Always

Steps to Reproduce:
Upgrade to 20081113 nightly.
This is from bug 414038, see bug 414038 comment 96, bug 414038 comment 100.
Blocks: 414038
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: regression
OS: Windows Vista → All
Hardware: PC → All
This is an intentional regression to allow us to land code that enables development to advance quicker in multiple directions. David and Bryan need to file bugs on the UI that will replace the columns.
Duplicate of this bug: 465040

Comment 4

11 years ago
Posted patch patch v1 (obsolete) — Splinter Review
I did promise I'd restore this functionality, despite my disagreements with it. This patch also fixes bug 465267.

NOTE: nsTextFormatter doesn't seem to be available to javascript, making the MB/KB labels difficult to deal with. The simplest option was to switch the %d to %S. The problem here is obviously that we're past the string freeze. Option 2 is to (temporarily) hardcode those strings and then re-localize them post-beta1. Option 3 is to hold this patch until post-beta1.
Assignee: nobody → jminta
Status: NEW → ASSIGNED
Attachment #348667 - Flags: review?(bugzilla)

Comment 5

11 years ago
Simon,
   Can you comment on the concerns addressed in comment #4. How often do "MB" and "KB" require a translation? How glaring would it be to have hard-coded values?

Comment 6

11 years ago
Option 4 would be to use the toolkit versions of these strings (used in the download manager) http://mxr.mozilla.org/comm-central/source/mozilla/toolkit/locales/en-US/chrome/mozapps/downloads/downloads.properties#50
Lets not add these columns back in.  The extra columns require an advanced pref to be turned on.  There is a lot of wasted space that your folder pane such that it requires a large amount of space for all the numbers to be visible.  You could spend a lot of time resizing the columns to make sure everything fits with optimum space.  You can't even sort by the columns, not that we really want to.  None of that seems like a good experience, I'm pretty sure the ENIAC had clearer readouts than this layout.

Plus the use case for this is fairly unclear (at least to me) exactly what people need here, especially compared to what we had planned.  From what I understand the expanded columns provides 3 extra pieces of information.

* Unread
* Total
* Size

For the unread column we should be providing the number beside the name of the folder so people can see how many are actually unread.  I'm not sure why we haven't been doing this all along.  This should be on by default.

*Inbox (2)*

With this we should also be able to provide an option to show the total number of messages as well.  (this doesn't come out looking good in ascii art because it requires font color changes and the bold needs to wrap around but the effect is simply like this.)

*Inbox (2*/320*)*

And though I seriously doubt that people need constant visible dashboard of the size of their folders... this could be done as well with a light colored font (indicated by the //) instead of a separate column.  I'm sure there are lots of people who've grown accustomed to this feature but I think there's a better way to manage or monitor space.

*Inbox (2*/320*)*  //5KB//

We might want a separate chooser for which folders show this kind of folder details or a per folder [x] for "folder details" would allow people to get that extra information they want on a per folder basis.
(Reporter)

Comment 8

11 years ago
Unless you are going to add an option to right-justify the Read/Unread information, I don't feel that what you're suggesting comes close to what the previous behavior provided.

I, for one, have always felt that reporting the unread counts as (essentially) part of the folder name is bad UI design.  I have always found that layout to be very difficult to visually scan, especially when multiple levels of folders are involved.

I want to be able to scan down a *single* column of information that will give me the data that I require about my folders, without having to continually scan back and forth through multiple levels of nesting to see it.  I don't want to have to read every folder name (bold not withstanding) - it's supposed to be informative, not a novel.

And yes, I *do* require a "constant visual dashboard of the size of [my] folders".  Your workflow may not include these, but for many people, it does.
(Reporter)

Comment 9

11 years ago
Note: 'size' means number of messages, to me.  Folder size in SI units doesn't matter to me, though I'm sure it does to others.
(In reply to comment #6)
> Option 4 would be to use the toolkit versions of these strings (used in the
> download manager)
> http://mxr.mozilla.org/comm-central/source/mozilla/toolkit/locales/en-US/chrome/mozapps/downloads/downloads.properties#50

That sounds like a good solution to me.
(In reply to comment #7)
> We might want a separate chooser for which folders show this kind of folder
> details or a per folder [x] for "folder details" would allow people to get that
> extra information they want on a per folder basis.

I think we'd want both - show folder size in the properties dialog, and a
dialog to show all of them at once. Although that's a bit of duplication,
having them all together at the same time I expect would be wanted by most
people.

(In reply to comment #8)
> And yes, I *do* require a "constant visual dashboard of the size of [my]
> folders".  Your workflow may not include these, but for many people, it does.

Why? If you didn't have the numbers, what wouldn't you be able to
do/judge/decide? Please give us actual use-cases so as to help us understand
why you really need it.
Assignee: jminta → david.ascher
The use case for showing total count is, from the interviews I've done, that some people want some folders to be empty, and manage their workflow so that their work is not done until that count is 0.  For everyone I've talked to, that requirement applies to _a few_ folders, not all.  

I'll be filing a bug after chatting w/ clarkbw to specify how people can set that UI on a per-folder basis.   

I'll also file another bug about giving people a way to manage the overall space (both counts & size) of their accounts, which is a great use case which I don't think is best suited by the folder pane.  

I believe that these two new capabilities will provide even better UI for the use cases we've identified, and let us have heterogeneous items in the folder pane, which in turn will be very helpful for other use cases.
Followup Bugs 465564 and 465568 have been filed. 

If there are other use cases which those two bugs don't solve, let's file new bugs and deal with those there.
Status: ASSIGNED → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → WONTFIX

Updated

11 years ago
Attachment #348667 - Flags: review?(bugzilla)
(Reporter)

Comment 14

11 years ago
Requiring users to configure that layout *per folder* is ridiculous.  I have several hundred folders, and I want it enabled in every single one.

#465564 also does not provide for display in a column format, which as I stated in comment #8 is critical, IMO.   My folder list should be visually scanable - it's not a novel that I should be required to read line by line to determine the information I'm looking for.

Attaching those pieces of data to the folder name is not a user-friendly UI.

Whether you like it or not, unless it comes very close to the legacy feature, it's not going to be adequate.
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
Jay -- please answer Mark Banner's question about the goals that you're trying to achieve, not by describing the specific UI you want, but by describing the underlying needs.  Then we can figure out how to best deal with those goals.
(Reporter)

Comment 16

11 years ago
The use you listed in #12 is a big one
Overall message count as an identifier for archival and/or purging is another.

It also seems like you don't understand that the layout of the UI *is* part of the goal, and it's at least as important as the first use case.  The ability to quickly scan a column for information about my folders is a use case in itself.  

If columns were of no informational use, we'd just do all our spreadsheets in a text editor.  Without a column alignment, the user must scan the entire line to determine the information they're looking for.  It's slower and more frustrating, especially to people who use email all day long.

The folder name is one piece of information, unread is another, total count is yet another.  They need to not be grouped together as if they were all a single piece of data.
(Reporter)

Comment 17

11 years ago
Another way to look at it:

If all the data about a folder is a single piece of information (and thus represented in a single column), then all of the data about a message is also a single piece of information.

All of that data represents a single message, therefore it must not warrant extra columns either.  (Sorting can be done without columns, so that alone is not a reason to keep them in the message pane.)

So, why does the message pane have multiple columns?  Because it's easier to read large amounts of data that way.

Comment 18

11 years ago
Maybe bring back option to turn on folder pane columns with advanced pref and work on the bugs that should imitate the usage they were providing ?
When all these bugs would be fixed it can be decided if "classic" display is still needed or modern one should cater all user needs.
Jay, re usage in #12 -- do you need to work hundreds of folders down to a count of 0?  

Re: the advantages of columns: what are you looking for when vertically scanning through the # of messages?  

About the information-theoretic approach -- there are lots and lots of information about folders that we could display.  # of Unread messages is of value to a lot of users for most folders.  # of read messages is of value to a fair number of users for a few folders.  

From a cognitive point of view, having numbers displayed that do not help the user accomplish what they're trying to do will make it harder for them to find the information they need.

As a bit of background, one additional problem with the columnar model is that it doesn't apply to non-folder things.  We want to move to a world where we can have things other than folders in there, such as calendars, todo lists, who knows what.  It may be that for some users, having the columns is the best way to do things, but we don't want to limit the extensibility of the folder pane because it's been "just" a folder pane. 

It'd be interesting to build an add-on that reinstated the columns for those users who desperately need them.  I'm still trying to drill down on the actual benefit that those columns provided, because I still think that in many cases, we can provide the same benefit without compromising the extensibility of the UI.

Hope this helps.

Comment 20

11 years ago
(In reply to comment #19)
> As a bit of background, one additional problem with the columnar model is that
> it doesn't apply to non-folder things.  We want to move to a world where we can
> have things other than folders in there, such as calendars, todo lists, who
> knows what.  It may be that for some users, having the columns is the best way
> to do things, but we don't want to limit the extensibility of the folder pane
> because it's been "just" a folder pane.
so in other words the only workaround for not wanted columns applying to non-folder things is to fully remove the columns ?
if these new things would not be folders couldn't they "not fully" integrate to the folder pane such that columns would not apply to them ? (or stick columns to the local folders or sth like this)
Przemyslaw: unfortunately, as far as I know the implementation of columns in the current XUL tree widget doesn't let us do "per-kind" columns.

Note that there is a gecko bug which would allow us to do richer styling of treecells (bug 441414),  which should allow us richer ways of displaying things, so we should be able to do column-like displays in the future.

Comment 22

11 years ago
Thanks for the bug id, I've heard about it but didn't yet read it.
So with this bug fixed (there is some work already) there could be no topic ? adding dependency ?

Comment 23

11 years ago
I've create an extension which turns on these columns (as opposed to using a preference). To use it, you must have today's nightly or later, though. You can give it a try here: https://addons.mozilla.org/en-US/thunderbird/addon/9716

Comment 24

11 years ago
Here's my personal use case:
I use the number of total messages as a to-do list, with a goal of getting to zero.  I use that functionality for the Inbox and Drafts folders on a regular basis, and perhaps on a less frequent basis for other folders.

I do want to be able to see the total number of messages for a given folder. I can do that today in the status bar, so that works in my case as a workaround.

I use IMAP folders. Sometimes I run up against a quota and have to move mail messages locally.  I need to be able to find the biggest folders to take action.  Sometimes it's just one message with a big attachment.  Sometimes it's just that I have thousands of messages.  Either way, I need a way to find the bloat.  I don't care what mechanism the client provides.  

The suggestion of grouping the info together works for me if there's a pref to enable the verbose mode:
*Inbox (2*/320*)*  //5KB//

But I wouldn't care if that information was provided in some other way.  For example, I sometimes use the Zimbra web mail/calendar interface.  That UI presents the number of unread:
*Bugzilla (50)*
and then provides a tooltip that contains the total number of messages, and the folder size.

Anyway, just some data points. Hope that helps.

Comment 25

11 years ago
(In reply to comment #7)
> Lets not add these columns back in.  The extra columns require an advanced pref
> to be turned on.  There is a lot of wasted space that your folder pane such
> that it requires a large amount of space for all the numbers to be visible. 
> You could spend a lot of time resizing the columns to make sure everything fits
> with optimum space.  You can't even sort by the columns, not that we really
> want to. 

This is not true! I would absolutely love to be able to sort by the folder size. We have an ISP limit on IMAP storage, and this would help greatly in order to identify if some large messages are lurking somewhere in a mailbox.
Sorting folders by size is an excellent idea.  Sorting the folder pane by size isn't necessarily the best way to accomplish this hunt for large messages.  

Another view that is specifically tuned towards helping people manage their space, especially good for quota management, would help with this.  Something this view could provide is a much more detail breakdown of where the space is being used.  Attachments vs. Messages is something that would be an interesting way of analyzing this information.  

 Name         Count  Size (MB)
 -----------------------------
 Folder X            630
   Messages     400  430
   Attachments  22   200

Also, with more space in a, say separate tab, we could offer graphical breakdowns of each account and folder.  Or... we could try to cram little pie charts into the folder pane :)

Like Bob mentions in comment 24, managing size is something that people need to do.  However we can do this in a much nicer way than overloading the folder pane.

Comment 27

11 years ago
(In reply to comment #26)
> Sorting folders by size is an excellent idea.  Sorting the folder pane by size
> isn't necessarily the best way to accomplish this hunt for large messages.  

It is for me. I see the largest folder. I click on it. I sort by message size. Find a few and delete or move. It cannot get any simpler. This is why this bug needs to get fixed!

Comment 28

11 years ago
Please, let's not get sidetracked on what is already a contentious bug. This bug exists solely to debate restoring the columns. A separate bug would handle sorting by those columns. Nonetheless, I've provided the extension that does the first part (see comment #23), which I think is all the more reason to WONTFIX this bug. That extension brings the behavior back for those who want it.

Comment 29

11 years ago
I'm sorry, I just want to view the columns, as you said. I don't care about sorting until I open the folder. Thanks to those working on this bug to bring back the columns.

Comment 30

11 years ago
In line with comment #23 and comment #28, I'm resolving this as WONTFIX. For those that want the columns, installing the extension will provide them. As davida described, the thunderbird core is looking at other solutions beyond the folder-pane.
Status: REOPENED → RESOLVED
Last Resolved: 11 years ago11 years ago
Resolution: --- → WONTFIX
Whiteboard: [see comment 23 for add-on to do this]

Comment 31

11 years ago
(In reply to comment #23)
> I've create an extension which turns on these columns (as opposed to using a
> preference). To use it, you must have today's nightly or later, though. You can
> give it a try here: https://addons.mozilla.org/en-US/thunderbird/addon/9716

Where do we report bugs for this extension?
Also, look at Bug 297853 where some Icon attachments show an alternative to text labels. With Icons the Col width can be cut to ~2.4em.
Duplicate of this bug: 466612

Comment 33

11 years ago
I know this will be unuseful to say this but wontfixing this bug is a regression in both usability and interface display.

If you want to push user out of thunderbird, it could be a solution. Having some kind of columns - just to know number of messages in each folder - is something which is present in every single mail client.

Just my opinion, of course.

Comment 34

11 years ago
(In reply to comment #31)
> Where do we report bugs for this extension?
You can add comments/review to the add-on with bug reports. I know the management panel discourages that, but amo doesn't have a better system worked out yet.

(In reply to comment #33)
Is there some reason that the add-on is insufficient for your needs (or the needs of the other users that you say will be pushed out)?

Comment 35

11 years ago
Just for you info, I installed the extension since. But it will be far better to get these columns back in any form.

Many people won't search for an extension for such a basic feature, even if it fills the gap left by this bug.

Comment 36

11 years ago
Frank, we probably want some version of the patch here or the mentioned add-on in the SeaMonkey version of the JS-driven folder pane.
Sorry for the bugspam to everyone else.

Comment 37

11 years ago
60+ users here, and now considering our options if this sort of thing gets swept under the rug.

Comment 38

11 years ago
Defenetly a regression for me. 

What is the point not including this functionality in the 3.0, when it was in Tb2.0 and is available as an extention (have not tried it, since I stay on pre-this-bug build)?

Comment 39

11 years ago
Come on, right now I dislike it too, but if Mozilla guys want to make something even better up, why not let them at least try it before saying that it's just plain wrong?

Let's just install the extension from Comment #23 for now, and watch those other bugs.

Comment 40

11 years ago
Agree from me also that this is a regression. My question is, why especially do you want to have it out when it is an _option_ people might or might not use? If you don't use/like it, just turn it off (which it is, when you do a clean install). If you don't want to waist the space on your screen, turn it off. This is about choices! Please put the "option" back in.
My personal use:
- workflow using the number of messages; I don't use unread
- Size for the need to compress yes/no (I know it can be done automatically, but I want to control it myself).
Of course, if the development team comes up with another solution I am open for it , but just bumping it out seems a bit to simple.

Comment 41

11 years ago
> (In reply to comment #33)
> Is there some reason that the add-on is insufficient for your needs (or the
> needs of the other users that you say will be pushed out)?

I found the add-on after some agressive Googling, and thank you for it!  (Can you eliminate the unnecessary zero for folders with no unread message, though?  That would fully restore the previous usage and would be much appreciated.)  But I agree with those here who say that a useful feature has been lost, and I imagine many users will not know to look for the add-on that restores it.
Duplicate of this bug: 497726
Duplicate of this bug: 509208
Version: unspecified → Trunk
For future reference the add-on for this is located here:
https://addons.mozilla.org/en-US/thunderbird/addon/9716

Comment 45

10 years ago
I use the unread message count to watch my emails which i have yet to process. That is not equal with being unread, because i might read an email and decide to process it later. That's why every email is tagged as to-do on receiving. And then i have a smart folder which catches all emails with this tag.

That the reason why i need the total column.

And then i automatically sort my incoming email. This way the unread mail is distributed over several folders. Putting the unread message count directly behind the folder name is really a regression in usability. I would say it is a usability nightmare. Yes, you can find the unread emails, but it much harder than having the separate column. As someone pointed out, you can't scan over your folder tree quickly to find unread mail. (And don't let me start about the grey folder names.) Even Outlook Express does it better with the unread count in blue instead of black. Try to find a '(1)' in a mix of long and short folder names and then in a separate column. Whoever came up with the idea to concatenate the folder name with information about the content should be really ashamed.

That's the reason why i need the unread column.

reply to comment 7:
A lot of wasted space? After installing TB3 i thought about the amount of unused whitespace. 
Please check the calender. It is almost 2010. Almost everyone is using widescreen monitors. Most emails are wrapped after 72 characters. And even if the email is not wrapped after 72 characters but are auto-wrapped in the message pane, the longer the text lines the harder it is to read the text. So what is the reason to gain 30 pixels of horizontal space if there is no shortage of space in that direction? (And to be honest, i don't even use a widescreen monitor with TB, at least not for the main window. Still i don't need extra space and would rather have a usable display of unread messages)
And even if you would really need the additional space, the argument is flawed, because if there is an unread mail in the folder with the longest name, the unread message count is displayed exactly where the column would be. No big difference. (Yeah, i know the folder name will be shortened in the middle, but i hate that.)

So, why don't do it as an add-on?
1. Hard to find. I normally find almost everything, but this add-on was shown to me in a forum. If you try to find a solution to get the columns view back, you only find how to enable it in TB2.
Many users probably won't find it and would blame TB because it lacks this option.
2. The add-on is not localized, it's only in english. No big deal for me, but definitely for others.
3. Add-ons depend highly on the author. If new version of TB are released the compatibility is checked too late and the add-on will be disabled. And after some time the author might lose interest in the add-on and abandon it.

The removal of this option is a bad decision.
At least make the unread message count configurable, so that it can be aligned to the right side of the folder pane.
Duplicate of this bug: 533835

Comment 47

10 years ago
Can someone explain how to use the add-on referenced in this thread?  First, on installation (on TB3.0), it complained about a version incompatibility.  I unzipped the add-on, changed em:maxVersion to 3.0 in install.rdf, and zipped it back up again.  Then the installation appeared to work, but after TB was restarted, the functionality was not there, nor was the add-on listed under Tools > Add-ons.  TIA.

Comment 48

10 years ago
RE: Comment 47: I hacked a fix.  For some reason, during installation, the folder "chrome" did not get copied from the add-on archive into its proper destination.  Manually copying it made it work, and also allowed the add-on to be listed under Tools > Add-ons > Extensions.

Comment 49

10 years ago
(In reply to comment #48)
> RE: Comment 47: I hacked a fix.  For some reason, during installation, the
> folder "chrome" did not get copied from the add-on archive into its proper
> destination.  Manually copying it made it work, and also allowed the add-on to
> be listed under Tools > Add-ons > Extensions.

Would it be too much to ask for a consolidated "how-to" for making this actually work with TB3.0?

This functionality *really* should be put back into TB3.0.  I have no problem with it being enabled by an advanced setting, but an "add-on" seems excessive and short-sighted.

Comment 50

10 years ago
Amen to Emil's comments (both of them) and to the MANY other requests from people technically savvy enough to use Usenet.  Imagine how many people that don't use newsgroups or bugzilla are disappointed.  Between this regression and the abhorrent waste of space in the new headers I abandoned the TB3 betas and will remain on TB2 and encourage others to do that too.  If the functions are not eventually restored then at some point we will look for another alternative mail and news program.

Add-ons can never be counted on to be kept current with TB releases, let alone version changes.  That makes them undesirable for those of that are technical and unpleasant for those of us that provide technical support to others.

Comment 51

10 years ago
I spent several days looking for a solution to be able to see the columns which are super important for me. As I gave up and decided to report the bug I found this and realize that somehow it is a big issue. I dont understand why the feature was removed and personally think it should be fixed. Just look at how many people are reporting this as a bug. At least put a link to the extension in the release notes or have it presinstalled or something. Just removing a feature with no notice is really bad.
Duplicate of this bug: 535578

Updated

10 years ago
Summary: "Expanded Columns" in the folder pane are no longer available → "Expanded Columns" in the folder pane are no longer available to select columns for display for message total count and folder size
Whiteboard: [see comment 23 for add-on to do this] → [see comment 23 for add-on to do this][duptome]

Comment 53

9 years ago
the addon https://addons.mozilla.org/en-US/thunderbird/addon/9716  is now compatible with TB3.0  It is so strange that this functionality migrated from the core to an addon, why did the developers wasted time removing this, and force people to install the addon? If the addon is so simple why not bring the feature back?
Duplicate of this bug: 558068
Duplicate of this bug: 556146

Comment 56

9 years ago
Staarting to build up the duplicates here. Maybe it is time to reopen this bug.
Duplicate of this bug: 592349

Updated

7 years ago
Duplicate of this bug: 537528

Updated

5 years ago
Duplicate of this bug: 1024380
I complained about this issue before this bug was even filed in bug 414038 comment 75. The addon referenced in this bug, that was only originally created (under protest by the author) because some of us complained, is now the third most popular extension for Thunderbird, behind only Lightning and it related google provider extension.

It seems like events have made it pretty clear that this was a mistake to remove. Changes to the folder pane that were supposed to be done that added new features never occurred, the popularity of the addon shows that users believe there is a use case for this, and promises to add better ways to get at the data never occurred. Meanwhile the addon itself was abandoned by its original author, and taken over by core Thunderbird developers because it is so critical.

Can we ever admit a mistake? Let's admit it, reopen this bug, and merge the functionality of the addon into core.
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---

Updated

5 years ago
Assignee: davida → nobody
(Assignee)

Comment 61

5 years ago
Yes, I vote for this and would be willing to work on this. I am familiar with the code of the Extra folder columns extension and I have fixed some stuff in it, even added the display of accumulated subfolders data if the parent folder is collapsed.

We just need confirmation from UI guys and reviewers that it would be accepted back into core. The columns turned off by default but normally exposable, no pref needed.
Flags: needinfo?(mkmelin+mozilla)
Flags: needinfo?(josiah)
Flags: needinfo?(bwinton)
The extra functionality that was hoped for never did appear, but having extra columns in that tree view seems really odd, and crufty, to me.  We'll see what Josiah and/or Paenglab think, but I would accept a patch that re-added the columns if, and only if, it didn't add an extra line of header to the default configuration.  (Also, it's hard for me to give a more firm commitment without seeing a screenshot.)
Flags: needinfo?(bwinton)
(In reply to Blake Winton (:bwinton) from comment #62)
> The extra functionality that was hoped for never did appear, but having
> extra columns in that tree view seems really odd, and crufty, to me.  We'll
> see what Josiah and/or Paenglab think, but I would accept a patch that
> re-added the columns if, and only if, it didn't add an extra line of header
> to the default configuration.  (Also, it's hard for me to give a more firm
> commitment without seeing a screenshot.)

What do you mean by an extra line of header?
Posted image Screenshot (obsolete) —
I'm pretty sure he means the header that appears at the top of the folder pane (See screenshot). I completely agree that this should *not* be shown by default and should be hidden with a preference. Not necessarily hidden in about:config, but not visible by default.
Flags: needinfo?(josiah)
(Assignee)

Comment 65

5 years ago
Then how do you propose the user enables/toggles the additional columns?
Hidden pref, of course!  ;)

(More seriously, there are already options that control the folder pane in the View menu.  Something there seems appropriate.)
(Assignee)

Comment 67

5 years ago
Great, so instead of standard UI and tree infrastructure (e.g. the column picker widget) we open-code some new UI used nowhere in TB :)
A menu option to show a table header is hardly new.  :)
(Assignee)

Comment 69

5 years ago
It is, if you call it "table header". If you at least call it "toolbar" then yes, that does already exist :)
We seem to have a fundamental disagreement about the importance of this option. Since 200,000 users managed to install this addon (which requires a lot of effort to even know it exists) then it is pretty clear that this is important functionality. If we have important functionality, we should be exposing it so that it is easy to find. The users have already spoken pretty clearly that this is important. It seems to me that the onus is one you guys, Blake and Josiah, to say why you believe that the usual interface for exposing folder columns should be hidden in this case. Buried in a menu is far from clear.

If it were fully up to me, I would add a folder pane header that had a dropdown menu to select the folder type on the left, and the standard icon to show columns on right. The ability to switch folder display types is also functionality that was buried for reasons I never understood (and yes I use the addon that restores that functionality).

I don't understand "but having extra columns in that tree view seems really odd, and crufty, to me" What is the issue here?
(Assignee)

Comment 71

5 years ago
It seems hiding/showing the column headers is doable. So it can be toggleable as an option in View->Folders.
Assignee: nobody → acelists
(In reply to :aceman from comment #71)
> It seems hiding/showing the column headers is doable. So it can be
> toggleable as an option in View->Folders.

This sounds like a good place.

Can we also add the expunged column of the addon in bug 750569?

I also need to point out that a review in https://addons.mozilla.org/en-US/thunderbird/addon/extra-folder-columns/ states "... on TB31.1, TB has a strange behavior when I enable the display of the SIZE column: When I scroll the folder pane, TB freeze few seconds. When I disable the SIZE column, the scrolling is fine."  

Coincidentally, I am working with a user who experiences slowness with message deletes with this addon and gfx.direct2d.disabled = false (true resolves it).  Not sure yet if it is also slow when scrolling folder pane.
(In reply to Kent James (:rkent) from comment #70)
> We seem to have a fundamental disagreement about the importance of this
> option. Since 200,000 users managed to install this addon (which requires a
> lot of effort to even know it exists) then it is pretty clear that this is
> important functionality. If we have important functionality, we should be
> exposing it so that it is easy to find. The users have already spoken pretty
> clearly that this is important. It seems to me that the onus is one you
> guys, Blake and Josiah, to say why you believe that the usual interface for
> exposing folder columns should be hidden in this case. Buried in a menu is
> far from clear.
> 

Since this is a popular feature, I have changed my mind about saying we should *not* show it by default. I actually think it's fine to show by default. However, I would like a way to hide it, since it does add clutter to the pane, and I (and many others), will want to remove it. But of course, an add-on could be made to hide it quite easily, so let's just move ahead with this bug.
As a long time user, not saying I'm representative, I'm in the "wanting cleaner UI, i.e. no column header camp" so I'd want at minimum a non-addon method to not show column header.

> We seem to have a fundamental disagreement about the importance of this option. 
> Since 200,000 users managed to install this addon (which requires a lot of 
> effort to even know it exists) 

I'm not one to be a naysayer, but I'm going to play devils advocate 
- I'm not convinced that it is difficult for users to find said functionationaility - do we have information that indicates this?  And, if it is difficult does that not say more about lack of publicity, visibility and findability of addons ... a big failing on our part?
- Further, 200k may be a large number but I'm not convinced that 200k means that a significant percentage of the other 12M users (or whatever the number is) would want this.
I'm happy to have it disabled by default, but it would be good if there was some hint at the point of the missing columns that shows that there is something there that is hidden. I'm not sure what it is called, but I will attach a file that shows the arrow in the separator that is sometimes used.

As for "I'm not convinced that it is difficult for users to find said functionationaility":

There is a hierarchy of feature discovery here:

1) Always shown
2) not shown but contextual hint (which is what I want)
3) not shown, but enabled with a non-contextual preference ui (what blake wants)
4) not shown, you have to locate an addon to find that it even exists
5) enabled with a hidden preference.

You think 4 -> 2 is a small leap, I think it is a huge leap. And 200k is massive in the context of addons for Thunderbird. 2% of our users using anything but a core feature is already huge.

Ideally, what I would expose in the extra line would contain, on the left, a dropdown box to allow you to select different folder groups (All, Smart, Favorites, etc). and also show the treeview column icong that hints that more icons can be seen.
That's a grippy. They're a bit out of fashion though.

I think I'm somehere around #3, like Blake. We'd need a menu item kind of thing somewhere anyway so... 

It would be nice if there was a way to customize the folder pane in general. Choosing folder modes, combining folder modes etc.
Flags: needinfo?(mkmelin+mozilla)
We could have a floating disclosure arrow, like the one at the right of https://www.dropbox.com/s/i5i2xrs2ua3fge7/Screenshot%202014-10-20%2009.35.29.png?dl=0  I don't know how it would look in context, but perhaps that would be a reasonable compromise?

(This is all in addition to the menu item, which I believe everyone agrees we should have. :)
(Assignee)

Comment 79

5 years ago
(In reply to Kent James (:rkent) from comment #75)
> You think 4 -> 2 is a small leap, I think it is a huge leap. And 200k is
> massive in the context of addons for Thunderbird. 2% of our users using
> anything but a core feature is already huge.

Based on the numbers presented recently on the summit, this actually makes it the 4th most used addon for TB. So I think having a separate addon for this simple and small functionality is strange.

Ok, I'm going to code something up :)
(In reply to Blake Winton (:bwinton) from comment #78)
> We could have a floating disclosure arrow, like the one at the right of
> https://www.dropbox.com/s/i5i2xrs2ua3fge7/Screenshot%202014-10-20%2009.35.29.
> png?dl=0  I don't know how it would look in context, but perhaps that would
> be a reasonable compromise?
> 
> (This is all in addition to the menu item, which I believe everyone agrees
> we should have. :)

I was thinking the same thing, because in general discoverability s*cks all around - I'm all for discoverability that doesn't impede the rest of the UI. This could easily cover comment 77, which are also not so discoverable. 

As Kent says it may be a big leap for a user to know that something could improve the folder pane. What I was only suggesting is it isn't worse than anywhere else in our UI. But we don't have metrics on whether users know that addons exist and how to get one that's relevant to their needs But if we think users finding functionality via addons s*cks then we should go a step further and improve it (which is a different bug) ... wouldn't it be great if right+click (or something) allowed a user to look up addons in context of the UI area being clicked?
"in general discoverability s*cks all around ... I was only suggesting is it isn't worse than anywhere else in our UI" is not a particularly strong argument for avoiding discoverability.

Comment 82

5 years ago
(In reply to :aceman from comment #71)
> It seems hiding/showing the column headers is doable. So it can be
> toggleable as an option in View->Folders.

A checkbox or radio button would work. You know, like the green "Read/Unread" button?

Comment 83

5 years ago
(In reply to Magnus Melin from comment #77)
> That's a grippy. They're a bit out of fashion though.
> 
> I think I'm somehere around #3, like Blake. We'd need a menu item kind of
> thing somewhere anyway so... 
> 
> It would be nice if there was a way to customize the folder pane in general.
> Choosing folder modes, combining folder modes etc.

(In reply to Blake Winton (:bwinton) from comment #78)
> We could have a floating disclosure arrow, like the one at the right of
> https://www.dropbox.com/s/i5i2xrs2ua3fge7/Screenshot%202014-10-20%2009.35.29.
> png?dl=0  I don't know how it would look in context, but perhaps that would
> be a reasonable compromise?
> 
> (This is all in addition to the menu item, which I believe everyone agrees
> we should have. :)

(In reply to Worcester12345 from comment #82)
> (In reply to :aceman from comment #71)
> > It seems hiding/showing the column headers is doable. So it can be
> > toggleable as an option in View->Folders.
> 
> A checkbox or radio button would work. You know, like the green
> "Read/Unread" button?

How about just plain old "More..." up above where the columns would be?
(Assignee)

Updated

5 years ago
Blocks: 1103333
(Assignee)

Comment 84

5 years ago
Posted patch patch v2 (obsolete) — Splinter Review
WIP patch of the feature. It basically puts the "Extra folder columns" extension directly into TB core, main part in folderPane.js. It also contains my modifications (like localization fixes, summarizing of the properties across subfolders). I've been running with most of the modifications for about 2 years now.

You can enable the column headers via View->Layout->Folder pane columns (until you do that, the current default display should not be affected by this patch). This integration into TB is all new, so please check it and see if it is the right approach. I also use a global pref for it, so all windows with a folder pane share the setting. E.g. the folder pane itself can be toggled per window.
Toggling the columns in one window will not toggle them in all other windows. But will save the global pref so after restart all windows are the same. Not sure if the dynamic toggling is necessary.
There are also some open questions. E.g. if we want to hide the additional columns if "folder pane columns" are toggled off? Or they just stay there without headers?

Strangely the patch does not contain some stuff Joey's patch v1 is doing. I don't know if the missing parts are needed as the addon was also going without them. Maybe the XUL platform has improved since 2008?
Attachment #8528640 - Flags: feedback?(kent)
Attachment #8528640 - Flags: feedback?(bwinton)
Attachment #8528640 - Flags: feedback?(bugzilla2007)
Comment on attachment 8528640 [details] [diff] [review]
patch v2

(Redirecting to Josiah, because I think he and I are on the same page, and I'm going to be crazy busy for a while…)
Attachment #8528640 - Flags: feedback?(bwinton) → feedback?(josiah)
Comment on attachment 8528640 [details] [diff] [review]
patch v2

Yes I like it! Thanks for doing this.

I'm not completely sure about the star added to note that a folder is a summary. I like the idea of arking this (I've been fooled before by the lack of such a marker) but not sure about the star. I tried sigma and sigma blank, did not like them better. Underlining is another common nomenclature for a sum, perhaps that might work.

But I can live with the star.

The other thing that we really need, and perhaps you could add in another bug, is some better method to switch between folder display styles. That is, replace the "Name" part of the column header with a dropdown that allows you to select which folders are being viewed.
Attachment #8528640 - Flags: feedback?(kent) → feedback+
(Assignee)

Comment 87

4 years ago
(In reply to Kent James (:rkent) from comment #86)
> I'm not completely sure about the star added to note that a folder is a
> summary. I like the idea of arking this (I've been fooled before by the lack
> of such a marker) but not sure about the star. I tried sigma and sigma
> blank, did not like them better. Underlining is another common nomenclature
> for a sum, perhaps that might work.
> 
> But I can live with the star.
Yes, the star is just a placeholder character and we can now get the UX guys to choose a better one for English. I have made it localizable so any language can choose its own fitting character.

> The other thing that we really need, and perhaps you could add in another
> bug, is some better method to switch between folder display styles. That is,
> replace the "Name" part of the column header with a dropdown that allows you
> to select which folders are being viewed.
I didn't understand this. What are the options for which folders could be viewed? We have the View->folders menu. Looks like this is for a new bug if you could spec the feature more thoroughly.
I've reopened bug 700976 for the issues I suggested in comment 87.
Comment on attachment 8528640 [details] [diff] [review]
patch v2

Review of attachment 8528640 [details] [diff] [review]:
-----------------------------------------------------------------

I like this for the most part and I think it's pretty much fine. However, the extra columns should definitely be removed from the pane when you uncheck "Folder Pane Columns". Other than that, looks good to me.
Attachment #8528640 - Flags: feedback?(josiah) → feedback+
(Assignee)

Comment 90

4 years ago
Posted patch patch v3 (obsolete) — Splinter Review
OK, I addressed the remaining issues. So this could be ready for review.

Aryx, please push to try server, all tests.
Attachment #348667 - Attachment is obsolete: true
Attachment #8500632 - Attachment is obsolete: true
Attachment #8507655 - Attachment is obsolete: true
Attachment #8528640 - Attachment is obsolete: true
Attachment #8528640 - Flags: feedback?(bugzilla2007)
Flags: needinfo?(archaeopteryx)
Attachment #8557379 - Flags: ui-review?(josiah)
Attachment #8557379 - Flags: review?(mkmelin+mozilla)
Attachment #8557379 - Flags: review?(kent)
(Assignee)

Updated

4 years ago
Status: REOPENED → ASSIGNED
Priority: -- → P2
Comment on attachment 8557379 [details] [diff] [review]
patch v3

Review of attachment 8557379 [details] [diff] [review]:
-----------------------------------------------------------------

There were a few small nits and one comment with substance. r=me with requested changes implemented.

::: mail/base/content/folderPane.js
@@ +2223,5 @@
> +                "folderWithAccount", [text, this._folder.server.prettyName]);
> +          }
> +
> +          // If the unread column is shown, we don't need to add the count
> +          // to the name

Nit: period at end of sentence.

@@ +2235,5 @@
> +                                  [text, gFolderStatsHelpers.addSummarizedPrefix(unread)]);
> +          return text;
> +
> +        case "folderUnreadCol":
> +          return gFolderStatsHelpers

Nit" missing ; at end

@@ +2239,5 @@
> +          return gFolderStatsHelpers
> +                   .fixNum(this._folder.getNumUnread(gFolderStatsHelpers.sumSubfolders));
> +
> +        case "folderTotalCol":
> +          return gFolderStatsHelpers

Nit: missing ; at end

::: mail/locales/en-US/chrome/messenger/messenger.properties
@@ +485,5 @@
> +## %1$S = folder name
> +## %2$S = account name
> +folderWithAccount=%1$S - %2$S
> +## LOCALIZATION NOTE(folderWithUnreadMsgs):
> +## This is a concatenation two strings to compose a folder label with unread messages.

Nit: "concatenation of two strings"

::: mailnews/base/util/nsMsgDBFolder.cpp
@@ +4193,5 @@
>    NS_ENSURE_ARG_POINTER(numUnread);
>  
> +  bool isServer = false;
> +  nsresult rv = GetIsServer(&isServer);
> +  NS_ENSURE_SUCCESS(rv, rv);

I am seeing on a newly created IMAP account that the sizeOnDisk is -1 for the root folder, and stays that way after restart. That means that the UI always has ??? next to the imap account name. You fixed that issue in unread and totalMessages, but not in folderSize. Since that is calculated for each folder, you need to add this same check to the overridden values of GetSizeOnDisk for IMAP, local, and news folders.
Attachment #8557379 - Flags: review?(kent) → review+
Comment on attachment 8557379 [details] [diff] [review]
patch v3

Review of attachment 8557379 [details] [diff] [review]:
-----------------------------------------------------------------

Didn't we use to make the Total etc. columns reasonably sized. They not take up way too much space before you resize them. And why does the Name column have the dropmarker.

::: mail/base/content/folderPane.js
@@ +2273,5 @@
>    get level() {
>      return this._level;
>    },
>  
> +  getProperties: function ftvItem_getProperties(aColumn) {

function naming is no longer useful

@@ +2798,5 @@
> +     */
> +    addSummarizedPrefix: function(aValue) {
> +      if (!this.sumSubfolders)
> +        return aValue;
> +      else

no else after return

@@ +2833,5 @@
> +            .QueryInterface(Components.interfaces.nsIMsgFolder);
> +          let subSize = this.getFolderSize(subFolder);
> +          if (subSize == this.kUnknownSize)
> +            return subSize;
> +          else

no else after return

::: mail/base/content/messageWindow.js
@@ +550,5 @@
> +  let folderPaneCols_menuitem = document.getElementById('menu_showFolderPaneCols');
> +  if (folderPaneCols_menuitem)
> +    folderPaneCols_menuitem.setAttribute("hidden", "true");
> +
> +  folderPaneCols_menuitem = document.getElementById('appmenu_showFolderPaneCols');

nit: prefer double quotes wherewhere
Attachment #8557379 - Flags: review?(mkmelin+mozilla)
(Assignee)

Comment 94

4 years ago
Posted patch patch v3.1 (obsolete) — Splinter Review
OK, I have removed the arrow on the Name column. I don't think we allow sorting of the folders in any mode. I also made the widths of the 3 new columns start at 50px by default. The user can then resize them. Also, they are not flexible now, so resizing the folderpane only flexes the Name column. Josiah, please see if 50px is a reasonable starting point on all platforms.
Attachment #8557379 - Attachment is obsolete: true
Attachment #8557379 - Flags: ui-review?(josiah)
Attachment #8560746 - Flags: ui-review?(josiah)
Attachment #8560746 - Flags: review?(mkmelin+mozilla)
Comment on attachment 8560746 [details] [diff] [review]
patch v3.1

Review of attachment 8560746 [details] [diff] [review]:
-----------------------------------------------------------------

The context menu for it still needs to be fixed to show the options, like the thread pane one. Besides that, r=mkmelin

::: mail/base/content/folderPane.js
@@ +2810,5 @@
> +     * so that the property is initialized from the db.
> +     */
> +    fixNum: function(aNumber) {
> +      return (aNumber < 0 ? this.kUnknownSize :
> +              (aNumber == 0 ? "" : this.addSummarizedPrefix(aNumber)));

double ternaries are hard to read. 
maybe do the if (aNumber < -1) return his.kUnknownSize; first

::: mail/locales/en-US/chrome/messenger/messenger.properties
@@ +493,5 @@
> +## LOCALIZATION NOTE(summarizedValue):
> +## This string shows an indication that the value shown is actually a summary
> +## accumulated from all its subfolders.
> +## %S = summarized value from all subfolders
> +folderSummarizedValue=*%S

shouldn't the star be after the value?
Attachment #8560746 - Flags: review?(mkmelin+mozilla) → review+
(Assignee)

Comment 96

4 years ago
(In reply to Magnus Melin from comment #95)
> Comment on attachment 8560746 [details] [diff] [review]
> patch v3.1
> 
> Review of attachment 8560746 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> The context menu for it still needs to be fixed to show the options, like
> the thread pane one. Besides that, r=mkmelin
Which context menu? The "show columns" checkbox is in the main menu and the appmenu. Which other menu do you mean?

> ::: mail/base/content/folderPane.js
> @@ +2810,5 @@
> > +     * so that the property is initialized from the db.
> > +     */
> > +    fixNum: function(aNumber) {
> > +      return (aNumber < 0 ? this.kUnknownSize :
> > +              (aNumber == 0 ? "" : this.addSummarizedPrefix(aNumber)));
> 
> double ternaries are hard to read. 
> maybe do the if (aNumber < -1) return his.kUnknownSize; first
OK.

> ::: mail/locales/en-US/chrome/messenger/messenger.properties
> @@ +493,5 @@
> > +## LOCALIZATION NOTE(summarizedValue):
> > +## This string shows an indication that the value shown is actually a summary
> > +## accumulated from all its subfolders.
> > +## %S = summarized value from all subfolders
> > +folderSummarizedValue=*%S
> 
> shouldn't the star be after the value?
The string wouldn't align in the column as nicely in that case. MB in one row wouldn't be under MB in the previous row, etc.
(In reply to :aceman from comment #96)
> Which context menu? The "show columns" checkbox is in the main menu and the
> appmenu. Which other menu do you mean?

What you get when you right click the folder pane column header (Name).
(Assignee)

Comment 98

4 years ago
That menu shows options for the currently selected row (i.e. folder). No options for the columns or header itself. That seems intentional. So what do you mean? Do you want it to instead show options to toggle columns as in the message list pane?
Yes I think that's preferable. Context menus usually show options for a context, not for what is selected elsewhere.
(Assignee)

Comment 100

4 years ago
(In reply to Magnus Melin from comment #99)
> Yes I think that's preferable. Context menus usually show options for a
> context, not for what is selected elsewhere.
Yes, but it seems to be default behaviour of a <tree> to show the same context menu for the headers as for the data rows. In firefox, it even shows the context menu AND sorts the column, on the single right-click. What a mess :)

It seems the threadpane (message list) has made special hacks to override this. I am looking for that code.
(Assignee)

Comment 101

4 years ago
Posted patch patch v3.2 (obsolete) — Splinter Review
Is suppressing the context menu enough? :)
Attachment #8560746 - Attachment is obsolete: true
Attachment #8560746 - Flags: ui-review?(josiah)
Attachment #8561080 - Flags: ui-review?(josiah)
Attachment #8561080 - Flags: review?(mkmelin+mozilla)
I have one suggestion, having used this a bit while working on bug 1093217.

I find the ??? for no known value too intrusive. That usually means to me "Something was output that could not be interpreted" and looks like a bug. May I suggest a simple dash instead, "-"?

Otherwise, awesome! Let's get it into TB 38!
Comment on attachment 8561080 [details] [diff] [review]
patch v3.2

Review of attachment 8561080 [details] [diff] [review]:
-----------------------------------------------------------------

::: mail/base/content/folderPane.js
@@ +2204,5 @@
> +    return this.getText("folderNameCol");
> +  },
> +
> +  getText(aColName) {
> +      // Only show counts / total size of subtree if the pref is set,

this whole block seems to use 4 space indention. should be 2

@@ +2772,5 @@
>    }
>  }
>  
> +var gFolderStatsHelpers = {
> +    kUnknownSize: "???",

agreed "-" might be better. or just "?"

::: mail/base/content/mailContextMenus.js
@@ +297,5 @@
> +  // We do not want to show the context menu if clicking on the column headers.
> +  document.getElementById("folderTree").treeBoxObject
> +          .getCellAt(aEvent.clientX, aEvent.clientY, row, col, elt);
> +  if (row.value == -1)
> +    return false;

regarding this, for the thread pane it is done in CM_setTarget
http://mxr.mozilla.org/comm-central/source/mail/base/content/nsContextMenu.js#425

::: mail/base/content/mailWindowOverlay.js
@@ +710,5 @@
>  
>  /**
> + * Show or hide the headers of the folder pane columns.
> + */
> +function MsgToggleFolderPaneCols()

this is just used once and a one-liner, so please just inline it. we should get rid of such functions rather than add more of them
Attachment #8561080 - Flags: review?(mkmelin+mozilla) → review+
(Assignee)

Comment 104

4 years ago
Posted patch patch v3.3 (obsolete) — Splinter Review
OK, I think I solved the header context menu. I just used "after_start" to show the popup, instead of "before_start" that was used at the message list pane (I do not understand why it wanted the menu above the headers).

Josiah, there were some UI changes since your last review. Can you check them quickly so we can land this? It has all other reviews. Thanks.
Attachment #8561080 - Attachment is obsolete: true
Attachment #8561080 - Flags: ui-review?(josiah)
Attachment #8564633 - Flags: ui-review?(josiah)
Attachment #8564633 - Flags: review+
(Assignee)

Comment 105

4 years ago
Posted patch patch v3.4Splinter Review
Forgot to remove the useless function.
Attachment #8564633 - Attachment is obsolete: true
Attachment #8564633 - Flags: ui-review?(josiah)
Attachment #8564731 - Flags: ui-review?(josiah)
Josiah in comment 89 already gave a mostly positive response to this. It's now had plenty of review. Let's give Josiah another day to respond, but land it on 2/20 if we don't hear from him. He already said his availability is very low now.
(Assignee)

Comment 107

4 years ago
It is just that since his review some UI elements were changed (the - instead of ??? and the nonstandard (albeit better) context menu behaviour) so technically he should see it again. But yeah, feel free to land it anytime you wish. We can also land it and then polish it after that in new bug.
(Assignee)

Comment 108

4 years ago
OK, let's land it to get the strings in and polish it in new bugs.
Keywords: checkin-needed
Pushed as http://hg.mozilla.org/comm-central/rev/6e2b817f4dcc
Keywords: checkin-needed
Whiteboard: [see comment 23 for add-on to do this][duptome] → [leave open for final UI decisions][see comment 23 for add-on to do this][duptome]
Comment on attachment 8564731 [details] [diff] [review]
patch v3.4

Review of attachment 8564731 [details] [diff] [review]:
-----------------------------------------------------------------

Pretty good yeah.

Only two things I would suggest:
- Save the chosen columns when you switch back to Folder Pane mode, so that if the user goes back to Folder Pane Columns they won't have to re-enable the columns.
- Enable some columns by default, otherwise it's hard to notice that anything changed.

Both can be done in separate bugs.
Attachment #8564731 - Flags: ui-review?(josiah) → ui-review+
(Assignee)

Updated

4 years ago
Blocks: 1135536
(Assignee)

Comment 111

4 years ago
Thanks, filed bug 1135536 for those improvements.
Status: ASSIGNED → RESOLVED
Last Resolved: 11 years ago4 years ago
Resolution: --- → FIXED
Whiteboard: [leave open for final UI decisions][see comment 23 for add-on to do this][duptome] → [see comment 23 for add-on to do this][duptome]
Target Milestone: --- → Thunderbird 38.0
Keywords: feature
Whiteboard: [see comment 23 for add-on to do this][duptome] → [duptome]
(Assignee)

Updated

4 years ago
Blocks: 939462

Comment 112

4 years ago
(In reply to Magnus Melin from comment #93)
> Didn't we use to make the Total etc. columns reasonably sized.

****, wish I'd known this was being fixed...

I guess I'll go open a bug for making these column widths auto-adjust, so that they automatically resize themselves dynamically to the bare minimum needed to display the largest number, and no more...

Like how you can dbl-click on a column or row divider to auto resize the row or column to the size of the largest entry...

Comment 113

4 years ago
(In reply to Charles from comment #112)
> I guess I'll go open a bug for making these column widths auto-adjust, so
> that they automatically resize themselves dynamically to the bare minimum
> needed to display the largest number, and no more...

Done... see bug 1158597

Thanks again guys for reducing my Addon count by one... :)
Test in Moztrap https://moztrap.mozilla.org/manage/case/16265/
Let me know if anything is missing or incorrect.
Flags: in-moztrap+
(Assignee)

Comment 115

4 years ago
(In reply to Wayne Mery (:wsmwk, use Needinfo for questions) from comment #114)
> Test in Moztrap https://moztrap.mozilla.org/manage/case/16265/
> Let me know if anything is missing or incorrect.

Thanks, looks fine now.
(Assignee)

Updated

4 years ago
Whiteboard: [duptome] → [duptome][To enable the feature: View-> Layout-> Folder Pane Columns]

Comment 116

4 years ago
(In reply to Kent James (:rkent) from comment #86)
> Comment on attachment 8528640 [details] [diff] [review]
> patch v2
> 
> Yes I like it! Thanks for doing this.
> 
> I'm not completely sure about the star added to note that a folder is a
> summary. I like the idea of arking this (I've been fooled before by the lack
> of such a marker) but not sure about the star. I tried sigma and sigma
> blank, did not like them better. Underlining is another common nomenclature
> for a sum, perhaps that might work.
> 
> But I can live with the star.
> 
Correct me if I'm wrong, but the star seems to show up even when none of the child folders have unread messages, making it redundant as it is in effect a duplication of the arrow symbol on the left.

Comment 117

4 years ago
I have used the Extra Folder Columns add-on happily for several years.
I have just installed Thunderbird 38.1.0.  During installation, I was 
notified that this add-on was being disabled because it was           
incompatible.  I then found this bug discussion (464973), which       
indicates that the option for folder pane columns has been integrated 
into the Thunderbird base.  But the option is not visible!            
                                                                      
Eventually, on the description page for the old add-on, I found:      
                                                                      
"Yes, Extra Folder Columns is built in now, but in order to enable it 
you must modify with config editor the key                            
                                                                      
mail.folderpane.showColumns and set to true                           
                                                                      
ARB suggests to go to Options -> Layout -> click Folder Pane Columns  
but the option does not exist."                                       
                                                                      
I did this.  It had no immediate effect.  I restarted Thunderbird, and
then the folder pane column header appeared, with a column picker to  
add columns.  I am very pleased to have this feature back.            
                                                                      
In the hierarchy of feature discovery given in comment 75, the        
discoverability of this feature has been downgraded from              
                                                                      
4) not shown, you have to locate an addon to find that it even exists 
                                                                      
to                                                                    
                                                                      
5) enabled with a hidden preference.                                  
                                                                      
Was this the intention?
It's accessible via 
 - traditional menu bar: View | Layout | Folder Pane Columns
 - app-menu: Preferences | Layout | Folder Pane Columns
Also documented in the Thunderbird 38 what's new topic at https://support.mozilla.org/en-US/kb/new-thunderbird-38#w_expanded-folder-pane-columns  

Agreed, more discoverable would be desirable. As with most features.

Comment 120

4 years ago
(In reply to Magnus Melin from comment #118)
> It's accessible via 
>  - traditional menu bar: View | Layout | Folder Pane Columns
>  - app-menu: Preferences | Layout | Folder Pane Columns

Thank you, now I see it.
If you run with the traditional menu bar, the option is View | Layout | Folder Pane Columns .
Normally I don't run with the traditional menu bar.
In the application menu, under View, there is no Layout option.
I was getting ready to open a bug that in 38.1.0, the View / Layout option has been lost.
But thanks to your post, I now see that on the application menu, the option is under Options, not View:
Options | Layout | Folder Pane Columns .
(For me it is Options, not Preferences.)

Comment 121

4 years ago
(In reply to Wayne Mery (:wsmwk, use Needinfo for questions) from comment #119)
> Also documented in the Thunderbird 38 what's new topic at
> https://support.mozilla.org/en-US/kb/new-thunderbird-38#w_expanded-folder-
> pane-columns  
> 
> Agreed, more discoverable would be desirable. As with most features.

Currently, the What's New item for "Expanded Folder Pane columns" says:

"In the folder pane (the list of folders on the left), you can now show expanded options (Unread, Total and Size) View|Layout|Folder Pane Columns."

This applies to the traditional menu bar.

Should I change it to:

"In the folder pane (the list of folders on the left), you can now show expanded options (Unread, Total and Size).  In the traditional menu bar, select View|Layout|Folder Pane Columns ; or in the application menu, select Options|Layout|Folder Pane Columns ."

But in the app-menu, do some users have "Preferences" instead of "Options", as indicated in Comment 118?  Or was that comment imprecise?

If somebody who actually knows what they are doing wants to make the update instead of me, that would be even better.
Windows uses "Options", Linux and Mac use "Preferences".

Comment 123

4 years ago
This is to note that after some further discussion, Wayne Mery clarified the item "Expanded Folder Pane columns" in the article "New in Thunderbird 38.0" on Jul 22, 2015 at 2:17:26 PM.
(Assignee)

Updated

4 years ago
Blocks: 1190609

Updated

4 years ago
Blocks: 1158597

Updated

2 years ago
Duplicate of this bug: 515684
Keywords: feature
You need to log in before you can comment on or make changes to this bug.