For example, if I manually decrease width of Size column so that a file which is 112 bytes, shows "112 ...", then zip a folder, where the zip becomes 1.13 KB, the size column for the 112 byte file shows "112 byt..."
After deleting the new zip file, the Size column is resized to correct width. Same if a new column is added (eg. Created) - as mentioned in another post though, I'm not a fan of the way Opus sometimes resizes ALL column widths of auto-size columns, even though it shouldn't (eg. if I've manually changed width of auto-sized column, and a new column is added, I wouldn't expect Opus to resize the manually changed column width - that's a different bug-bear though - Don't auto resize columns when new column added/removed)
Already running beta 39, so not fixed on my machine. Have you tried the steps shown in video ?
If you expand the "New Folder" the column is resized to the correct width, so it looks like they are using two different code paths to determine width it should be.
Is this only an issue after manually resizing the column too small? That seems OK to me if so. Auto-sizing columns can be expensive (with a lot of files) so we try not to only do it in specific situations where something Opus has done would cause the column to not be wide enough. It isn't meant to correct manual resizes that already made the column too narrow (although it will correct them sometimes).
O.T. There appears to be a forum issue with uploaded animated GIF's (at least this one), as the animGIF actually starts when I manually resize the Size column smaller.
Back OT, it's after I manually resized Size column, but you'll noticed from video that the Size column width is resized after the ZIP operation (ie. initially "New Folder" column shows "0 by...", but then shows "0 bytes", while "bootTel.dat" initially shows "112 ..." but then shows "112 byt..."), so Opus is not correctly calculating the width of the text "112 bytes".
If I had to guess, the fix that @Jon mentioned recalculates the width based on the width of the Size text for the newly created ZIP file (ie. "1.13 KB"), and doesn't also include width of other visible items.
In other auto-column resize operations, Opus at least seems to use largest width of items that are visible.
Personally I would rather Opus calculated the max width of EVERY item, even if not visible, or at least make it optional, depending on actual slow-down from doing that. Would need a test build to see if it really slows it down too much.
Re. optional part, when disabled, it would just use visible items. When enabled it would do all, or better would allow user to specify max amount of items.
I agree with that for the most part, mainly to do with "Name column", as that's the column that has the most variation in potential width. Things like adding/removing a column results in Opus resizing width of all columns - something I wish didn't happen - ie. It should only remove the column, leaving widths of all others untouched, or add the column, with the new column width being resized to either the max width of column text of visible items, or of all items (depending on prefs).
