XYplorer Beta Club

admin wrote:Relative syntax: "?:\" as pattern would match any drive, as portable only XY's drive.

Yeah, but then so would "*:\" since one cannot use ":" anywhere else anyways, right? So if for some reason one wanted to do such a pattern, it could be done. You just have to remember that "?:\" is a "special" XY feature...

admin wrote:I will see what I can do about .\ and ..\ -- but relative to what? To app path or app data path?

To what is it relative everywhere else ? No reason this should be any different than say PFA, Color Filters, etc

admin wrote:I'm not aware of having changed anything. The interaction between tab memory and FV is a bit complex, especially with locked tabs that lead to automatic tab switches. I don't see where I could improve this.

Well, as I said, when trying it seemed to me that when switching tab the FV of the new location was loaded, so that's good (even though probably because it was of course also the tab settings!), but I still say FV should win over Tab, so XY should load settings from FV, not tab, thus
- taking into account an updated FV since tab was active
- affecting the column visibility as well (not affected now since it's a global setting, not tab-wise)

Oh yeah, and (XY/Env) variables support might be useful also, I haven't checked whether or not it's there yet...

jacky wrote:

admin wrote:Relative syntax: "?:\" as pattern would match any drive, as portable only XY's drive.

Yeah, but then so would "*:\" since one cannot use ":" anywhere else anyways, right? So if for some reason one wanted to do such a pattern, it could be done. You just have to remember that "?:\" is a "special" XY feature...

Yep, I do it, you'll see...

jacky wrote:

admin wrote:I will see what I can do about .\ and ..\ -- but relative to what? To app path or app data path?

To what is it relative everywhere else ? No reason this should be any different than say PFA, Color Filters, etc

App path.

jacky wrote:

admin wrote:I'm not aware of having changed anything. The interaction between tab memory and FV is a bit complex, especially with locked tabs that lead to automatic tab switches. I don't see where I could improve this.

Well, as I said, when trying it seemed to me that when switching tab the FV of the new location was loaded, so that's good (even though probably because it was of course also the tab settings!), but I still say FV should win over Tab, so XY should load settings from FV, not tab, thus
- taking into account an updated FV since tab was active
- affecting the column visibility as well (not affected now since it's a global setting, not tab-wise)

Cannot produce a bug here.

jacky wrote:Oh yeah, and (XY/Env) variables support might be useful also, I haven't checked whether or not it's there yet...

Yes, but performance comes into play now. If you have 1000s of FVs and possibly multiple patterns for each, then resolving ENVs might be notable as delay.

I'll wait with this.

admin wrote:Cannot produce a bug here.

Fresh XY v7.40.0018
- go to D:\Folder
- Columns = Name, Size
- Sort by Size DESC
- Save FV (remembers everything)
- goto D:\
- Columns = Name, Size, Created, Modified
Sort by Name ASC
- goto D:\Folder (col/sort from FV)
- goto D:\ (col/sort as "default")
- Open New Tab (D:\)
- goto D:\Folder (col/sort from FV)
- click on tab @ D:\ (sort updated, still only the columns from FV !!! Now this has become our new "default")
- Bring back Created & Modified manually
- goto D:\Folder (col/sort from FV)
- goto D:\ (col/sort as "default")
- switch to tab @ D:\Folder (again: sort updated, columns from default and not FV !!! Need to go to D:\ and back to fix this...)

admin wrote:Yes, but performance comes into play now. If you have 1000s of FVs and possibly multiple patterns for each, then resolving ENVs might be notable as delay.

What about XY vars ? Then people could use <xydata> if they needed to.
(Couldn't you just resolved the ENV vars at startup, and that's it. No more delay there, and you only update the FV when one does "Refresh Env. Cache" ?)

Something else I find annoying : set a FV for D:\Folder including subfolders. Now go to D:\ (no FV, back to default) then into a subfolder (e.g. D:\Folder\foobar) and realize you didn't want subs included after all. You could hit the "Edit" command and disable that option, but then you would also turn loose your default FV as it would be updated with the currently loaded one (FV for D:\Folder) since it's loaded, you're there, no more FV applied.

I wish that since I'm editing the FV and it doesn't apply anymore, XY would treat that as a change of location and, thus, restore my "default" FV instead.

jacky wrote:

admin wrote:Cannot produce a bug here.

Fresh XY v7.40.0018
- go to D:\Folder
...

Ah yes, sure. As you said, this is because Column visibility is global and not per tab. The tab does not care about it.

This is a problem that will concern all settings (also any future additions to FVS) that are not known by the tabs. Currently this is Column visibility and Line Number visibility.

Bad.

2 Solutions:
1 - Take Column visibility and Line Number visibility out of FVS. Easy.
2 - Add Column visibility and Line Number visibility to tabs. Not Easy. Could be horror show.

admin wrote:2 Solutions:
1 - Take Column visibility and Line Number visibility out of FVS. Easy.
2 - Add Column visibility and Line Number visibility to tabs. Not Easy. Could be horror show.

Couldn't there be a third solution : after a change of tab, XY looks for a FV for that new location, and if there's one loads it up, and if not and we were on one (prev tab) load the default ?

IOW, behaves like this was just another change of location -- only difference would be from one non-FV location to another, as then Tab-settings would be loaded. Then we would get the expected results, and that would remain true whatever settings are added into a FV in the future!

jacky wrote:

admin wrote:2 Solutions:
1 - Take Column visibility and Line Number visibility out of FVS. Easy.
2 - Add Column visibility and Line Number visibility to tabs. Not Easy. Could be horror show.

Couldn't there be a third solution : after a change of tab, XY looks for a FV for that new location, and if there's one loads it up, and if not and we were on one (prev tab) load the default ?

IOW, behaves like this was just another change of location -- only difference would be from one non-FV location to another, as then Tab-settings would be loaded. Then we would get the expected results, and that would remain true whatever settings are added into a FV in the future!

I still think that tabs should take over FVs. When I go back to a tab I want to find it as I left it. Even selections and scroll position are retained, you cannot just apply a FV here.

admin wrote:I still think that tabs should take over FVs. When I go back to a tab I want to find it as I left it. Even selections and scroll position are retained, you cannot just apply a FV here.

hmm.. right, forgot about selection & scroll. But here's the thing though : at the moment I do NOT find the tab the way I left it, I find it partially that way, plus with some settings from that other tab I just left !

So I don't think the current situation is satisfying as it is now either. That said, it does bring us back to the 2 solutions you mentioned earlier, and it seems that obviously #1 is easier to do but #2 would be thought as better from a user POV, even outside of FVS I'd say.

It seems like what should happen when switching tab is like restoring a "temporary FV" stored for that tab, plus a couple extra tab-only settings that are selection & scrolling. Of course I have no idea whether or not that's (easily) doable...

jacky wrote:

admin wrote:I still think that tabs should take over FVs. When I go back to a tab I want to find it as I left it. Even selections and scroll position are retained, you cannot just apply a FV here.

hmm.. right, forgot about selection & scroll. But here's the thing though : at the moment I do NOT find the tab the way I left it, I find it partially that way, plus with some settings from that other tab I just left !

So I don't think the current situation is satisfying as it is now either. That said, it does bring us back to the 2 solutions you mentioned earlier, and it seems that obviously #1 is easier to do but #2 would be thought as better from a user POV, even outside of FVS I'd say.

It seems like what should happen when switching tab is like restoring a "temporary FV" stored for that tab, plus a couple extra tab-only settings that are selection & scrolling. Of course I have no idea whether or not that's (easily) doable...

"temporary FV"... well, it should live across sessions as well, so not that "temporary".

I agree that the current situation is satisfying as it is now either. But see no good solution ATM.

jacky wrote:Something else I find annoying : set a FV for D:\Folder including subfolders. Now go to D:\ (no FV, back to default) then into a subfolder (e.g. D:\Folder\foobar) and realize you didn't want subs included after all. You could hit the "Edit" command and disable that option, but then you would also turn loose your default FV as it would be updated with the currently loaded one (FV for D:\Folder) since it's loaded, you're there, no more FV applied.

I wish that since I'm editing the FV and it doesn't apply anymore, XY would treat that as a change of location and, thus, restore my "default" FV instead.

Yep. Done!

admin wrote:"temporary FV"... well, it should live across sessions as well, so not that "temporary".

Well, nothing says XY can't save such "temporary" FV along with other tab-settings that are saved whenever settings are saved. That was probably a bad choice of word on my part, I should have used internal instead.

jacky wrote:

admin wrote:"temporary FV"... well, it should live across sessions as well, so not that "temporary".

Well, nothing says XY can't save such "temporary" FV along with other tab-settings that are saved whenever settings are saved. That was probably a bad choice of word on my part, I should have used internal instead.

There would not be any difference to storing those properties with tabs right away -- at least from the users POV. But this would run into some problems concerning the GUI. If column visibility is per-tab, then the Columns menu should be under Current Tab menu. Even worse with Line Numbers which is implemented as part of List Style!

Looks like trouble... repectively like work ... I mean column visibility per-tab sounds quite natural, doesn't it? But think of the disadvantage (and the reason why it is implemented as it is): once you decide you want to see e.g. the Attributes column, you will have to do it for each tab.

admin wrote:But this would run into some problems concerning the GUI. If column visibility is per-tab, then the Columns menu should be under Current Tab menu. Even worse with Line Numbers which is implemented as part of List Style!

Yes, "Columns" might have to move under Current Tab (and thus be available on tab header's ctxt menu also).

Line number : Well, it's a weird one anyhow because it's under both List Style & Columns! So just remove it from List Style, so it's only under "Current Tab|Columns", and we're good. (Or remove it from Columns, but then it has to go away from FV as well... plus from ctxt menu of Name column header, and that might just be weird, too)

admin wrote:Looks like trouble... repectively like work ... I mean column visibility per-tab sounds quite natural, doesn't it? But think of the disadvantage (and the reason why it is implemented as it is): once you decide you want to see e.g. the Attributes column, you will have to do it for each tab.

Not necessarily, you could just use the same tip as when setting up the View : hold Shift while clicking to make it applied to all opened tabs