In short, you shouln't have the same column widths when one mode has 4 columns and the other mode has 5.
One compromise would be to have separate settings for the name column. The rest can be shared.
And you can't sort by the same column when one of the modes does not have it.
If you sort by rel. path in flat mode, tree mode will be sorted by name. Going back it will remain on name. I don't see it as a problem. Besides, how often do you switch between the modes?
Also, I like the fact that the header is a different colour in tree mode. Is it possible to do it in flat mode as well?
It's possible but difficult, so we are not going to do this in this version at least.
In short, you shouln't have the same column widths when one mode has 4 columns and the other mode has 5.
One compromise would be to have separate settings for the name column. The rest can be shared.
Having separate settings is the right approach, as it supports all possible workflows. I sometimes use different column configurations in both modes because of limited screen real estate (without scrolling).
I can see having different column widths store for different modes.
However, I'm not sure about separate storing of sorted column name. We can either do this but then toggling between modes will change sort order. So if I had sort by size in flat mode, and by time in tree mode, it may look awkward. Or we can treat relative path sorting as a special thing and store/restore it for flat mode if it was last used there, regardless of tree sorting. Both of these are not very attractive (and let's add the third option: keep what we have now).
psguru wrote: ↑Thu Feb 29, 2024 9:17 am
I can see having different column widths store for different modes.
However, I'm not sure about separate storing of sorted column name. We can either do this but then toggling between modes will change sort order. So if I had sort by size in flat mode, and by time in tree mode, it may look awkward. Or we can treat relative path sorting as a special thing and store/restore it for flat mode if it was last used there, regardless of tree sorting. Both of these are not very attractive (and let's add the third option: keep what we have now).
Treating relative path sorting as a special is actually a very good solution.
