Column autosize idea...

[kunkel321]

An idea of how to program the automatic sizing of column widths when in Details View...

In below image:
A = total pane width
B = Name column
C = width of everything other than Name column

For my own purposes (and maybe that of other people), C remains constant. So make B = A-C.
(As I write this, it occurs to me that this is probably already a pref option.. If so, where is the setting?)

[binocular222]

Tweak: AutosizeColumnsMaxWidth

[kunkel321]

Tweak: AutosizeColumnsMaxWidth

I think this is always a static number though (unless 0, unlimited). I'm imagining a 'dynamically' changing number. The idea is to always allow the maximum space for long file names, but also, always squeeze my other columns (Ext, Date, Size) in there so that I never have to use the horizontal scroll bar... Does that even make sense?

EDIT: Since XY has to always assess that tweak when drawing the pane, I'm guessing that the additional computational resources needed to calculate "B" (as defined above) would be negligible. (?)

[highend]

It does (I would like the same) but... it comes at a cost. At least for me.

If you use a high resolution 16:9 monitor and only the few standard columns (size, modified, created) the name column would be incredible large even if your (file / folder-) names aren't and it's getting harder to see which properties belong to what. At least if you don't use things like zebra striping (which I don't). So user defined rules how columns are sized would be required to fit everybody's needs...

[TheQwerty]

What happens when C > A?

[kunkel321]

It does (I would like the same) but... it comes at a cost. At least for me.[...].

Hmm.. Yea, good point about having the name column too far away... I guess maybe there'd need to be a point where C would stop getting larger. Especially if the XY window was maximized. I'm not sure have many resources would be involved to assess all that though... Still, for the majority of the time, this would maximize the amount of file name shown, while still leaving the other columns in view -- at least for my own purposes it would.

What happens when C > A?

I dunno... I guess the same rule would apply as does now when the width exceeds that above-mentioned tweak number...

[TheQwerty]

the name column would be incredible large even if your (file / folder-) names aren't and it's getting harder to see which properties belong to what.

I do use zebra striping but this is also my worry with the idea - though I really like the fact that it makes better use of the space available.
Another concern is how it affects double-click on empty space goes up and similar functions, since there wouldn't be much space left empty.

It makes me wonder:
1) The too long issue might be alleviated by having the option to right-align the name column (with icon on the right).

2) Many property columns have a relatively small variance in value width, while the Name column varies wildly, so why do the majority of users, myself include, keep the Name column to the left of the others? Just because we are used to reading left-to-right top-down?

If we moved the Name column to the right the width adjustments should be less annoying and it helps with the too long value issue above; or is it just too weird to accept?


Anyhow, I'm going to try moving my Name column right and seeing how long I last.

[highend]

Just because we are used to reading left-to-right top-down?
or is it just too weird to accept?
moving my Name column right and seeing how long I last

1. +
2. +
3. That'll be interesting

The name is a necessity to identify a file / folder. All other properties don't share this importance. Useful, sometimes necessary but you could live without them (for the moment). So showing all less important properties first (while reading from left to right) is not the way to go xD

I think that user defined rules (which are bound to folder view settings) are the right way to handle this dilemma.
Let the user decide how he wants to handle column sizes.

Sizes in % of visible area (depending on single or dual list view), in pixels together with priorities when what has to shrink / expand...

As Don would say: A can of worms^^

[TheQwerty]

3. That'll be interesting

So far, very weird.

2016-05-19 073414.png

[TheQwerty]

I think that user defined rules (which are bound to folder view settings) are the right way to handle this dilemma.
Let the user decide how he wants to handle column sizes.

Sizes in % of visible area (depending on single or dual list view), in pixels together with priorities when what has to shrink / expand...

Thinking about this...

If Don added the ability to trigger scripts when entering a FVS (as previously suggested), then we could script the re-sizing of columns.

We might not be able to achieve content-aware sizing, but we could certainly experiment with setcolumns and controlposition to add some user-defined rules.

[highend]

Cool idea! This would transfer the hard work (designing logic) to... em, us? oO *da..*

No really, great idea! Don?

[admin]

Well, might be slightly over the top...

[highend]

But a great enhancement (because you can do a lot more than "just" adjusting column sizes) when entering a folder...

[admin]

And a great can of worms...

[tiago]

And a great can of worms...

+1 for a wide open outdoor fishing