Feature: Add setting to always auto size columns to fit

[welles]

What's the Problem?

Like in the native file explorer, you have to manually resize columns or click 'Size all columns to fit' when working with very long / short file names

Requirements

• Add setting to always auto size columns to fit
• Entering a directory triggers auto size
• Adding / removing a file or folder triggers auto size
• Renaming a file or folder triggers auto size

Alternatives

There could be a hotkey to 'resize to fit' all columns in the current view, which would already be an improvement over having to right-click the column header bar and select 'Size All Columns To Fit'

[ELowry]

Here are a few possibilities worth considering:

1. Using a system to store the desired column width as a percentage once set; so resizing columns would keep that percentage value regardless of the window size. This has the disadvantage of not playing well with smaller windows; so having a—possibly configurable—"minimum width" could solve the issue.
2. Automatically setting the size of date/size columns based on the "typical" maximum value they should reach. This could let the Name column fill up all remaining space by default. A user-defined "minimum-width" for the Name column would prevent issues with narrow windows.
   • Ex: The longest day would be Wednesday, September 30, 2022 in the "system" style; which has a fixed width
   • Ex: The longest file size would be 900.00?B since anything with one more digit would roll over to the next unit.

[notDavid]

I think this will be useful for reference, the corresponding Directory Opus settings:

1. DOpus ( Archive )

Auto-size columns: This option causes column widths in details and power mode to be automatically sized to fit their contents. Instead of using this option, which affects all columns, you can also configure this on a per-column basis on the Columns tab.

2. DOpus ( Archive )

The Width column in the fields list lets you specify the width for individual columns. If the Auto-size all columns option on the Display tab (see below) is turned on, all columns will be shown with their widths as Auto (and grayed out to indicate that option is in effect) - editing an individual column's width will automatically turn off the Auto-size all columns option.

The options are:
Auto: Automatically size this column. This has the same effect as the Auto-size all columns option on the Display tab, but lets you apply it on a per-column basis.

Expand: Automatically sizes the column the same as Auto. The difference is the widths of Expand columns are ignored in the calculation of Fill columns (see below), and columns set to Expand will go off the right hand side of the file display rather than making Collapse columns start to collapse.

Collapse: Automatically sizes the column, but its width is able to collapse (down to zero width if necessary) to allow other fields to fit without horizontal scrollbars appearing. For example, you might want the Description column displayed, but not have it force other fields off the edge of the file display. Setting it to Collapse means it will only appear if there’s space for it.

Fill: Columns set to fill will be automatically sized to fill any available horizontal space in the file display. If there is more than one Fill column they divide the available space between them. Columns set to Fill can potentially end up wider than they need to be (contrast with Auto + Fill described below).

You can also enter a desired pixel width into the Width field.

[yaira2]

If there was an option to always auto size columns and you overrode a columns width, would you expect it to auto size the next time you navigated to the same directory?

[intergrav]

+1, I keep running into this issue where there is a big empty space in the file type area / name and it drives me crazy lol

You could fit a lot more if this were added.

[yaira2]

@intergrav we can solve that independently from this request by changing the default width of the type column.

[yaira2]

Adding / removing a file or folder triggers auto size
Renaming a file or folder triggers auto size

These can affect performance, I wonder if a hot key is the better way to do this.

[github59173]

I find it odd that this hasn't been added, nor has Windows directly added this functionality, even though a large number of users have requested it from Microsoft for over a decade. I might not be looking in the right places, but this is the best file manager look-alike I have seen for Windows 11, and this feature hasn't been added?

[Draise14]

Yeah, this too would be very nice. I found the unresponsive column width loosing a lot of space specially on widescreens.

[yaira2]

If there was an option to always auto size columns and you overrode a columns width, would you expect it to auto size the next time you navigated to the same directory?

I'd like to finalize this feature, but before this can be done, we need to settle on the behavior for the above-mentioned scenario.

[rhiinschnookele]

I would expect it to auto size the next time I navigate to the same directory. Thank you! Am 31.10.2024 16:53 schrieb Yair:

> If there was an option to always auto size columns and you overrode a columns width, would you expect it to auto size the next time you navigated to the same directory? I'd like to finalize this feature, but before this can be done, we need to settle on the behavior for the above-mentioned scenario. -- Reply to this email directly, view it on GitHub [1], or unsubscribe [2]. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

Links: ------ [1] #9377 (comment) [2] https://github.com/notifications/unsubscribe-auth/BLLMJQ2PQVUXPMIGWHV6DJTZ6JG6LAVCNFSM6AAAAABQ6TB2UCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDINJQGIZDQNRUHA

[ELowry]

If there was an option to always auto size columns and you overrode a columns width, would you expect it to auto size the next time you navigated to the same directory?

I'd like to finalize this feature, but before this can be done, we need to settle on the behavior for the above-mentioned scenario.

I can see two valid approaches to this:

1. Changing a column width changes it across the whole app (probably as a percentage width).
2. Changing a column width only affects the current folder, and is saved locally.

The first option is great for consistency and muscle memory (most people will "set & forget"), but can be a pain for people who have things like GIT folders that will have more columns than usual, and may start acting differently.
The second one can be great for power-users, but would likely require a button or something to "save current column widths as default" so that the user can override the defaults.

Back to my earlier message, this could also all be superfluous if the "default" layout is smart enough; as I was describing with using "minimum widths" to ensure all columns can display what they need; and then anything left (file name, git commit messages, etc.) are given a default value that determines how much of the remaining space they try to take over (and their minimum width as well, leading to overflow, naturally).

Depending on how hard these things are to implement, this could be worth A/B testing with some temporary option in pre-release?

[rhiinschnookele]

I would agree to "Depending on how hard these things are to implement, this could be worth A/B testing with some temporary option in pre-release?" Am 01.11.2024 12:48 schrieb Eric Lowry:

If there was an option to always auto size columns and you overrode a columns width, would you expect it to auto size the next time you navigated to the same directory? I'd like to finalize this feature, but before this can be done, we need to settle on the behavior for the above-mentioned scenario.

I can see two valid approaches to this: * Changing a column width changes it across the whole app (probably as a percentage width). * Changing a column width only affects the current folder, and is saved locally. The first option is great for consistency and muscle memory (most people will "set & forget"), but can be a pain for people who have things like GIT folders that will have more columns than usual, and may start acting differently. The second one can be great for power-users, but would likely require a button or something to "save current column widths as default" so that the user can override the defaults. Back to my earlier message, this could also all be superfluous if the "default" layout is smart enough; as I was describing with using "minimum widths [1]" to ensure all columns can display what they need; and then anything left (file name, git commit messages, etc.) are given a default value that determines how much of the remaining space they try to take over (and their minimum width as well, leading to overflow, naturally). Depending on how hard these things are to implement, this could be worth A/B testing with some temporary option in pre-release?

…

-- Reply to this email directly, view it on GitHub [2], or unsubscribe [3]. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***> Links: ------ [1] #9377 (comment) [2] #9377 (comment) [3] https://github.com/notifications/unsubscribe-auth/BLLMJQYF7KOE54BMSD7GD2LZ6NTAVAVCNFSM6AAAAABQ6TB2UCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDINJRG42DONJWGU

[yaira2]

What if a user overrode the width to be small, and then added a new file with a large name? Should the columns resize?

[ELowry]

What if a user overrode the width to be small, and then added a new file with a large name? Should the columns resize?

That would be the point of "minimum widths" based on the type of column IMHO. Though there's an argument to be made for respecting user choices, even if they make no immediate sense to the designer.

[yaira2]

@ELowry, I might be missing the connection between minimum widths and this feature request. One of the requirements mentioned by the original author is that adding or renaming a file should automatically resize the columns. My question is whether this requirement should still apply when the user has manually set the column sizes for a specific directory. I hope this clarifies my question.

[ELowry]

@ELowry, I might be missing the connection between minimum widths and this feature request. One of the requirements mentioned by the original author is that adding or renaming a file should automatically resize the columns. My question is whether this requirement should still apply when the user has manually set the column sizes for a specific directory. I hope this clarifies my question.

Edit: sorry, this got rambley, but these things are hard to communicate in writing.

Indeed; I was mostly focusing on the core idea of auto-resizing, and hadn't really re-read the initial requirements.
Unless I am mistaken, an issue with the current design is that columns have a fixed size, which doesn't change when a window is resized. So if a user optimizes widths for full-screen, most columns go to overflow when in windowed; and if optimized for a set windowed size, full-screen becomes full of wasted space to the right. Correct?

My personal stance on UX design is that it is not possible to ensure that everything is always displayed: file names can get massive, and having the name field auto-resize whenever a file name is edited is likely to lead to situations where all other columns get squashed.
I believe that the generally accepted UX design approach would be to focus on finding a good balance between the UI adapting to the width of the window, while ensuring maximum readability across a wide range of window widths and screen resolutions.

IMHO:

The file name tends to be the one that takes up the most space; so it would stand to reason to try and "optimize" all other columns to be as narrow as necessary, and give file names all available space.
This leaves 2 "problematic" scenarios:

• Below a certain width, it is likely to be impossible to properly fit all columns while still leaving space for the file name field. In this case, there are multiple possible approaches that can be taken, including "squashing" other columns some to try and keep the file name column readable; but also simply overflowing (as is currently the case). [this is the bit where a "minimum width" comes into play]
• For larger monitors, wider views could be hard to read if the file names are too far away from the other columns (if it's 60% of the whole width, and file names are short, it could be hard to associate the file names with the next column visually). So it could make sense to start scaling up the "secondary" columns' widths to "spread out" the information horizontally, which would keep things visible.

As for how to react to a user manually changing a column width. My gut feeling would be to aim to remember the widths of all columns except file names; which is set to take up all remaining space. Again, this is where a "minimum width" could be important.

[yaira2]

The "size to fit" feature isn't related to the window size, rather, it resizes the columns to fit the text regardless of the width of the window.

[dmorris68]

It feels like this request was intended for Details layout, so not sure if my request fits here, but it is related to auto-sizing column widths.

I'm more interested in List mode column widths. I pretty much live in List view mode, and much prefer Windows 10/11 default behavior of automatically sized List mode columns. Here's a Windows Explorer screenshot -- notice the long filenames sorted to the front make the first column very wide, but the subsequent columns of shorter folder names are quite narrow. This optimizes whitespace while still showing complete filenames.

Now compare the same folder shown in Files:

Here with the fixed column width you simultaneously have cut-off filenames in the left column, and excess whitespace in the other columns. Even more frustrating, unless I'm missing something, there's no way to manually resize the columns in List mode, so I'm left to hovering over the cut-off filenames and waiting for a popup to see the complete filename (in tiny hover print). Just not a good experience for me.

[yaira2]

It feels like this request was intended for Details layout, so not sure if my request fits here, but it is related to auto-sizing column widths.

@dmorris68 these are different requests, however you can refer to #1033 for more details.