Thanks for updating! I think this patch makes sense (and seems to work well) but I'm not too familiar with QTreeView, let's wait a bit for further feedback and merge it once Frameworks 5.45 has been tagged.

In D11993#241387, @ngraham wrote:

This patch is a breath of fresh air when using Detailed View or Detailed Tree View. You can resize the window and open and close the preview without wanting to kill something!

Such passion over a file dialog :)

Question: is expandNameColumn() even needed anymore with this change?

Give me a moment to comment it out again and re-check. I thought it was, but let me run another test.

I wasn't able to find any regressions stemming from removing that code, and once gone, I was able to hack out even more code that seemed to exist purely in support of it. Here's a diff that applies on top of this patch: https://paste.kde.org/p9z7riqdo

And while we're digging into this code, it would be quite nice to set QHeaderView::ResizeToContents for the other two columns so they always display the correct width and never have to be resized. That even fits under the umbrella of the patch's title "tweak column widths..."

In the works...

I'm to tired to test this myself, but could you please test this with the edge case where some file names are so long that they don't fit in the view? Also, Stretch disables manual resizing, right?' If that is also deemed useful, we could adapt the solution from https://centaurialpha.github.io/resize-qheaderview-to-contents-and-interactive. That's pyqt, but the same idea applies to C++. The resize event handling code is even already there, just needs to be adjusted.

I'll give that a test. I'm sure I can find a file (or make one up) with an absurdly long filename.

Once I figure out why @ngraham's uploaded diff won't apply... grr.

All seems to be well with the removal of the extraneous resizing code.

Here's the result of a test with a ridiculously long filename:

I think that looks perfectly reasonable.

Also, yes - Stretch has disabled the ability to manually resize the columns. Columns 1 & 2 are set to fit the size of their contents, while column 0 fills all the remaining space. Resizing the dialog results in only the Name column (column 0) to change size; the others stay fixed to the size of their contents.

Got a few code niggles, detailed below.

Function-wise, this is a vast usability improvement. And in case you have a really excessively long file name, you can just use Tree view (the non-details version), which only has one column.

I vaguely remember there was some code to delay resizing of the columns until all items were loaded for performance reasons. Please check the commit history before deleting code.

In D11993#241607, @cfeck wrote:

I vaguely remember there was some code to delay resizing of the columns until all items were loaded for performance reasons. Please check the commit history before deleting code.

File history during the frameworks era: https://cgit.kde.org/kio.git/log/src/filewidgets/kdiroperatordetailview.cpp

File history during the kdelibs era: https://cgit.kde.org/kdelibs.git/log/kfile/kdiroperatordetailview.cpp?h=Active/Two

Here's the commit from 2007 that added most of the code we're proposing to remove: https://cgit.kde.org/kdelibs.git/commit/kfile/kdiroperatordetailview.cpp?h=Active/Two&id=32af0ab2db10e64933b10c2434727b883441c0cf

Apparently the goal was to allow the columns to remain resizable before all the items had loaded. A bit of an odd goal, and I'm not able to reproduce the issue in my slow VM. Apparently hardware has become a bit faster in the past 11 years. :)

Of note: while digging, I found multiple commits that were attempting, unsuccessfully, to fix the problem that this patch fixes. It'll be nice to finally have it done. Overall, the spelunking expedition has made me more confident that this patch is sane.

Any more opinions on this? As you can see from the Summary section, it fixes (or obviates) a ton of bugs, many of them very old.

In D11993#244077, @broulik wrote:

The only downside this has is that you can no longer resize the column wider manually but then you might as well resize the window and actually see more :)

Precisely! :)

@sharvey, can you re-base this onto current master (git pull --rebase origin master)? It doesn't want to land.

Rebased (I think). Had to manually resolve a conflict. Hopefully it'll land now.

Merge errors tracked down and eradicated.