Open Bug 1158597 Opened 9 years ago Updated 2 years ago

Auto-size 'expanded columns' in the folder pane

Categories

(Thunderbird :: Folder and Message Lists, enhancement)

38 Branch
enhancement

Tracking

(Not tracked)

People

(Reporter: tanstaafl, Unassigned)

References

Details

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:37.0) Gecko/20100101 Firefox/37.0
Build ID: 20150415140819

Steps to reproduce:

Testing v38b3 and the new 'Expanded Columns' that was just restored (thanks!)...

Enabled the 'Size' column (the only one I have ever used).


Actual results:

1. The column was automatically made very wide, and had to be manually resized/adjusted.

2. The width changes as the window is resized.


Expected results:

The width of these columns should dynamically auto-adjust to the bare minimum needed to fit the largest datum in the particular column in the Folderpane.

Similar to how, in a spreadsheet (everyone I've ever used has this ability), dbl-clicking on a [column][row] divider will auto adjust the width of the [column][row] to the minimum needed to accommodate the largest datum that exists in said [row][column].
Component: Mail Window Front End → Folder and Message Lists
Blocks: TB38found
Severity: normal → minor
Depends on: 464973
The problem is, there is probably no support for autosizing in the XUL tree widget. And implementing it could be hard, as the width depends on the string length (in all rows) and the font size (i.e. how much pixels the strings actually take). Also, if the size column needs to be resized (widened), which column do you shorten? Probably Name.

In my usecase, folder sizes mostly only grow. The maximum width of the Size folder is for a string of *XXXMB. Or if you have a folder >1GB then 4 digits for the size. In my case setting the width to fit 999MB is enough for years. So what other case do you mean?

Or do you think about the case where user forces the display of size in KB (yes, we have that feature)? Then the string could be *1234567KB, slowly lengthening from 1KB to that max length.
Well, what I would personally envision would be only one column that can be manually resized - the name column. The default should be that it auto-adjusts to display the full name of the longest foldername, but the user could choose to truncate it if desired, but when the user manually changes the width, it should never change unless/until the user manually changes it again.

The Size column should auto switch from KB to MB to GB when the transition threshhold is reached (ie, instead of 1000KB, it would switch to 1.#MB, and instead of 1000MB, it would switch to 1.#GB

Last, the Unread/Total columns should simply auto-adjust - and when one reaches the point where it must be truncated, then whichever columns other than Name are being displayed (Unread, Total and/or Size) should share equally in the truncation. If the user doesn't want them truncated, they can either adjust the width of the Name column, or the entire Folder Pane.
(In reply to Charles from comment #2)
> The Size column should auto switch from KB to MB to GB when the transition
> threshhold is reached (ie, instead of 1000KB, it would switch to 1.#MB, and
> instead of 1000MB, it would switch to 1.#GB
This already happen, even though the highest unit is MB for now.

> Last, the Unread/Total columns should simply auto-adjust - and when one
> reaches the point where it must be truncated, then whichever columns other
> than Name are being displayed (Unread, Total and/or Size) should share
> equally in the truncation. If the user doesn't want them truncated, they can
> either adjust the width of the Name column, or the entire Folder Pane.
I don't think this is currently possible. We get no indication that a column is "full" and some text does not fit into it (gets the ellipsis truncation).
Ok, well, it is called a 'Feature Request' for a reason I guess... ;)

Bummer that it isn't (easily) possible though...
Surely it could be nice if implemented and set up in a clever way.
Severity: minor → enhancement
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Unspecified → All
Hardware: Unspecified → All
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.