Columns' & List's settings when going from SP to DP

[j_c_hallgren]

@ Don
can't you just automatically run a #1071 command on the 1st time DP is used, and load the FVS after that (if it exists)?

I could, but I'd find it weird. Sorry, I still don't understand the whole point of this.

Well, you may find it weird, but some of us appear to find the current method "weird" also, so we're trying to make it just a bit more user friendly, ok?

The pont is: Because when I open a new tab, the basic settings carry over to it so why should opening a new pane (ok, so technically it was open but not visible) cause my settings there to be some undesired factory defaults and not be like a new tab? It means one has to locate and perform an extra step that shouldn't be needed, IMHO.

As I wrote before (with some emphasis added now):

Because if I've got my SP set the way I want it, there is a very high probability that I'd want the DP to be identical, and not back to square one, and without having to do a command/function to copy settings

[ale]

It's a one time thing but I think it's about understanding the expected and most useful behaviour for the user. I was surprised from the first DP execution, so I can say I expected the same settings of the active tab I had in single pane mode. It is more evident if we activate DP with horizontal panes and have customized settings because if second pane has stock settings, all columns widths for example are not aligned between the two panes, there was not visual continuity for the eyes between the two panes. I can say I also expected the second pane to open on the location I had on the active tab in first pane, it opens instead on the Desktop. Finally in that situation when I looked for the command to transfer settings from a pane to the other I think I expected a command to "send" the active tab list configuration to the other pane, the available command was instead "take" the settings from the other pane, I think both may be useful.
And to tell the truth it's true, as j_c_hallgren says if we take the comparison with tabs in the same pane, it would be weird to Control + T and have the new tab with stock settings on the desktop

[admin]

It's a one time thing but I think it's about understanding the expected and most useful behaviour for the user. I was surprised from the first DP execution, so I can say I expected the same settings of the active tab I had in single pane mode. It is more evident if we activate DP with horizontal panes and have customized settings because if second pane has stock settings, all columns widths for example are not aligned between the two panes, there was not visual continuity for the eyes between the two panes. I can say I also expected the second pane to open on the location I had on the active tab in first pane, it opens instead on the Desktop. Finally in that situation when I looked for the command to transfer settings from a pane to the other I think I expected a command to "send" the active tab list configuration to the other pane, the available command was instead "take" the settings from the other pane, I think both may be useful.
And to tell the truth it's true, as j_c_hallgren says if we take the comparison with tabs in the same pane, it would be weird to Control + T and have the new tab with stock settings on the desktop

Well, I still don't like it.

But what about this: A toggle "Synchronized Pane Settings": If ON then all list setting changes on the active pane are immediately mirrored on the inactive pane (if inactive pane is invisible, then this could be done when showing it).

[ale]

I went experimenting a bit and was busy with this bug

Pane 1 with tabs A, B
Pane 2 with tab C
Tab A in pane 1 active
"Define Current Column Layout as Default"
Activate tab C in pane 2
Press button to set Folder View in toolbar
"There are stored settings..."
Press Cancel
Now the Folder View Icon is in pressed state
If we activate tab A in pane 1 again pressed state
If we activate tab B in pane 1 pressed state for tab A and C goes away

If we say OK to "There are stored settings..." and play with tabs again it seems a bit broken. What's the priority between define layout as default and folder view?

Edit: Sorry I missed a step to reproduce this

[admin]

I went experimenting a bit and was busy with this bug

Pane 1 with tabs A, B
Pane 2 with tab C
Tab A in pane 1 active
"Define Current Column Layout as Default"
Activate tab C in pane 2
Press button to set Folder View in toolbar
"There are stored settings..."
Press Cancel
Now the Folder View Icon is in pressed state
If we activate tab A in pane 1 again pressed state
If we activate tab B in pane 1 pressed state for tab A and C goes away

If we say OK to "There are stored settings..." and play with tabs again it seems a bit broken. What's the priority between define layout as default and folder view?

Edit: Sorry I missed a step to reproduce this

The "F" button is not updated on pane switch. I think this is the root of the bug. Thanks for noting it!

[j_c_hallgren]

Well, I still don't like it.

You said the same about DP way back when...

But what about this: A toggle "Synchronized Pane Settings": If ON then all list setting changes on the active pane are immediately mirrored on the inactive pane (if inactive pane is invisible, then this could be done when showing it).

Yes...IMO, that would be just fine and likely even better as it would be typical that I'd like to keep the two panes in sync...and...as long as the default value for new install would be ON!

[zer0]

I'd like to bump this up, if I may. Just tried to dip a toe into using DP again, but was visually reminded that columns' and list's settings don't carry over to the other pane. Back to SP I go. With FVS off, I don't see why there's no possibility of a tweak/setting which we can toggle to enable/disable the globality of aforementioned settings, argh...

[serendipity]

I'd like to bump this up, if I may. Just tried to dip a toe into using DP again, but was visually reminded that columns' and list's settings don't carry over to the other pane. Back to SP I go. With FVS off, I don't see why there's no possibility of a tweak/setting which we can toggle to enable/disable the globality of aforementioned settings, argh...

Go to the second pane where you want to apply settings to and run this from Address bar:
#1071
That translates to "Copy List Settings from Other Pane" in CKS
"Tools | Custom Keyboard Shortcuts | Miscellaneous"

[zer0]

Go to the second pane where you want to apply settings to and run this from Address bar:
#1071
That translates to "Copy List Settings from Other Pane" in CKS
"Tools | Custom Keyboard Shortcuts | Miscellaneous"

Thank you, it almost worked. Almost, because the "Name" column did not auto-resized while the other ones did.

[TheQwerty]

Thank you, it almost worked. Almost, because the "Name" column did not auto-resized while the other ones did.

Odd because it definitely seems to resize the column here.

[zer0]

Odd because it definitely seems to resize the column here.

Complete weirdness. I believe I've uncovered a bug here.

How the second pane behaves when that CKS is applied, it turns out, is entirely depended on the folder in the 1st pane from which the settings are copied, and behaves differently even if two different folders in the 1st pane have the same List Style settings. This, of course, should not happen. It appears that if the width of one of columns ("Name", for example) in the 1st pane (autosize is enabled, FVS is off) is greater than the current width of the same column in the 2nd pane then, when this CKS is invoked, this column in the 2nd pane is resized to the width of the respective column in the 1st pane. However, because it resizes it to the exact width of the respective column from the first pane, it fails to take into account the "Autosize columns" setting. In other words, that column in pane 2 is made to be wider than necessary.

[admin]

Odd because it definitely seems to resize the column here.

Complete weirdness. I believe I've uncovered a bug here.

How the second pane behaves when that CKS is applied, it turns out, is entirely depended on the folder in the 1st pane from which the settings are copied, and behaves differently even if two different folders in the 1st pane have the same List Style settings. This, of course, should not happen. It appears that if the width of one of columns ("Name", for example) in the 1st pane (autosize is enabled, FVS is off) is greater than the current width of the same column in the 2nd pane then, when this CKS is invoked, this column in the 2nd pane is resized to the width of the respective column in the 1st pane. However, because it resizes it to the exact width of the respective column from the first pane, it fails to take into account the "Autosize columns" setting. In other words, that column in pane 2 is made to be wider than necessary.

No bug. Auto-Size is an action triggered on browse. This command here (#1071) however is about copying list settings, so it copies the current column widths. If you want to trigger auto-size press F5.

[zer0]

No bug. Auto-Size is an action triggered on browse. This command here (#1071) however is about copying list settings, so it copies the current column widths. If you want to trigger auto-size press F5.

However, what use is it to copy over the settings without acting on them immediately. It's not something you can undo...yet, so why can't Auto-Size be triggered also? It feels like a job that has been half-done.

Further, why are column widths even copied? The only situation when it's logically correct to do so is when both panes have the same files, but what settings are copied over shouldn't be tangible against the files.

What if the folder in that tab in the 2nd pane will have its location locked and write permissions removed? In this situation, one would not be able to browse away from it or make changes to the file structure that may cause auto-refresh to be triggered.

I can't think of a reason why one would not want those settings to be executed immediately. If there are reasons, I'd like to hear them. Currently, there's no harm in triggering Autosize (if it's already enabled in the other pane) when the settings are copied over.

[zer0]

I have uncovered another inconsistency (read: bug) in a somewhat related area (read: couldn't be bothered to make a new thread).

To reproduce:
1. Enable Autosize columns in your View's List Style settings.
2. Browse to any folder and create a new (or rename an existing) file with a name long-enough to cause "Name" column to expand. Commit this rename either via mouse or "Enter". Result? "Name" column expands to accommodate this new, longer filename.
3. Now try to do the same to this (or any) file's extension. Result? When you commit the rename the "Type" column does not expand to accommodate new type description.

The same but opposite happens when you try to trim both name and extension. For the name the respective column narrows fine, but "Type" column stays the same when the extension is shortened to that which would cause Type description to be shorter too.

Clearly, there is an inconsistency in behaviour. Moreover, Don, you said that Autosize is triggered on browse. This does not appear to be the case in this instance, because I did not browse away and back to this folder, I stayed in it the entire time with auto-refresh disabled.

[admin]

I have uncovered another inconsistency (read: bug) in a somewhat related area (read: couldn't be bothered to make a new thread).

To reproduce:
1. Enable Autosize columns in your View's List Style settings.
2. Browse to any folder and create a new (or rename an existing) file with a name long-enough to cause "Name" column to expand. Commit this rename either via mouse or "Enter". Result? "Name" column expands to accommodate this new, longer filename.
3. Now try to do the same to this (or any) file's extension. Result? When you commit the rename the "Type" column does not expand to accommodate new type description.

The same but opposite happens when you try to trim both name and extension. For the name the respective column narrows fine, but "Type" column stays the same when the extension is shortened to that which would cause Type description to be shorter too.

Clearly, there is an inconsistency in behaviour. Moreover, Don, you said that Autosize is triggered on browse. This does not appear to be the case in this instance, because I did not browse away and back to this folder, I stayed in it the entire time with auto-refresh disabled.

Hmm.
1. Type column does auto-size on changing the extension over here.
2. It is a (automatic) rebrowse -- you just do not note it because it is too fast.