XYplorer Beta Club

Right now, all non-applied settings are simply inherited from the previous folder. I just wondered if it would be better to use the default settings instead (be it the internal/automatic or the defined <default>)?

I'd think the settings from the defined default FV should be used. But i haven't tested the last two beta versions yet so i still need some experience with the new possibilities...

hmm... I was gonna say this

jacky wrote:No, better as it is now, that's the natural/expected behavior I think.

Because if one sets a folder to say switch View to List, but not affect the Sort order, I'd bet the expected sort order shall be the current/last one used, not whatever is set on default!

But as I wrote that, I started to disagree with me, because I was dead wrong! (Okay not really, not that much, besides I may not always be right but I'm never wrong... )

I think it makes more sense to use the Default actually, and especially if that FV has the "Auto-save changes" option enabled! (does that mean it should be different if there's a DFV without auto-save enabled??)

Because if I am on FolderA with no FV set, sort order by Name ASC. Then I go to FolderB that has a FV to set sort order to Size DESC, then go to FolderC which FV sets View to List but doesn't affect Sort order, I think I expect my sort order to be the last one used (on a non-FV'ed folder), aka Name ASC, but not the last Sort order loaded because of a FV (Size DESC) as it applied to that one folder specifically.

So I'd say it should use the Default FV (should it be the internal one or not) instead, yes. In fact, to answer myself, I think even if there's a DFV with auto-save disabled, it should come from here as people are more likely to expect to find their (default) sort order than the one from the last FV loaded, as it is meant to apply to one specific folder (hence this whole feature...).

I guess it should remain the sort order (in this example) from last FV loaded only if there's a Default FV, which does not store the sort order. Then you don't change it, that'd be the expected behavior in that particular case, I believe.

jacky wrote:hmm... I was gonna say this

jacky wrote:No, better as it is now, that's the natural/expected behavior I think.

Because if one sets a folder to say switch View to List, but not affect the Sort order, I'd bet the expected sort order shall be the current/last one used, not whatever is set on default!

But as I wrote that, I started to disagree with me, because I was dead wrong! (Okay not really, not that much, besides I may not always be right but I'm never wrong... )

I think it makes more sense to use the Default actually, and especially if that FV has the "Auto-save changes" option enabled! (does that mean it should be different if there's a DFV without auto-save enabled??)

Because if I am on FolderA with no FV set, sort order by Name ASC. Then I go to FolderB that has a FV to set sort order to Size DESC, then go to FolderC which FV sets View to List but doesn't affect Sort order, I think I expect my sort order to be the last one used (on a non-FV'ed folder), aka Name ASC, but not the last Sort order loaded because of a FV (Size DESC) as it applied to that one folder specifically.

So I'd say it should use the Default FV (should it be the internal one or not) instead, yes. In fact, to answer myself, I think even if there's a DFV with auto-save disabled, it should come from here as people are more likely to expect to find their (default) sort order than the one from the last FV loaded, as it is meant to apply to one specific folder (hence this whole feature...).

I guess it should remain the sort order (in this example) from last FV loaded only if there's a Default FV, which does not store the sort order. Then you don't change it, that'd be the expected behavior in that particular case, I believe.

Yes, I think you are right. Especially because Pagat thinks the same.

It appears a conclusion has been reached but I just wanted to point out that I agree as well.

Even at this late point, I'll add my agreement also for the $.005 that it's worth...