Separate view settings for folders and files at least for full path/relative path/item name option

[Musenka]

Hello!

I'm examining FreeFileSync after using Unison file sync (https://www.cis.upenn.edu/~bcpierce/unison/) for many years. Unison is quite a smart application and I never had problems with it, but it's development is actually stalled for many years and it lacks some new features.

It's fully a matter of taste but I find Unison's default compare view a bit more clear for the user because it shows extended paths only for folder or the first file of folder, and all other files in the same folder are just tabbed by several spaces and do not contain paths. So looking at the first entry of the group which is either extended folder path or path of the first file in folder we can easily identify location. And at the same time all other files in the same folder do not contain paths at all (no excessive garbage text), but are marked with tabulation to identify that they are from the same folder. It sound a bit complicated but it's really very convenient. Here is an example

When I play with FreeFileSync I find items only mode too short (I cannot easily identify the real path because I see only the folder name) and at the same time I think relative/full path mode is too excessive for files - sometimes their names are truncated because of long paths.

I do not ask you to simulate Unison of course, but I think that allowing separate view settings for folders and files at least for full path/relative path/item name option will make FreeFileSync much more flexible and customizable. For example Unison-like view may be easily setup in FreeFileSync: enable full or relative path for FOLDERS and at the same time item name only for FILES - and that's all.

Possible additional improvements that should be also mentioned (they are directly related):
- Tabulation for files based on their nesting level (1-2 spaces per tab level is quite enough).
- Collapsing or hiding files in folder if they all have the same status. For example, in Unison, if one folder is completely new (on some side) and it contains many new files inside it - Unison just show this folder as one item (marked as new on some side) and do no show all these new files at all - they are hidden because the whole folder is new and the sync action (either auto or manual) is assigned to the whole folder at once. It's just an example of such approach. Hiding may be replaced by collapsing/extending by user request. This prevents text garbage.

But the main proposal is just to separate folder / file settings, make them independent from each other.

Thanks!
Sergey

[Musenka]

I should add that when I try to use FreeFileSync on my real-world sync pair (just the same pairs as in Unison which I currently use for the real synchronization) I face files with nesting levels even more than 10 so full/relative path option produces very ugly text lines for these files: all pane space is filled with a very long path and name of the file itself is completely truncated. It's really inconvenient.

If I try to switch to item name only mode, filename is OK, but it's location becomes hidden because only the innermost folder name is shown (above this file) and it contains not enough info to quickly identify it (because it's nesting level is too deep).

All these remarks are based on my multi-year experience of using Unison for rather big datasets and some experiments with FreeFileSync.

[Musenka]

I played a little more and found another related issue. The problem is that if view mode is set to items only (without paths), their related folders (paths) cannot be identified without manually hovering mouse over them.

See the following screenshots:

Screenshot_20200427_203128.png (37.2 KiB) Viewed 11198 times

Screenshot_20200427_213411.png (20.7 KiB) Viewed 11198 times

Both show the same items in 2 different view modes: with or without paths.
Let's assume additionally that path nesting is high (so item names on the first screenshot will be truncated because of long paths) and some of different items a located in the same folder (it's not so on these screenshots but that doesn't matter).

What can we see with additonal assumptions?

The first method (a) will show many truncated names and (b) it is not optimized for many items from the same folder (each item is always listed with it's long path even if this path is absolutely the same as for many previous/next items), it produces mach unwanted textual garbage (repeating long paths for items from the same folder).

The second method show pretty non-truncated filenames without their long paths but it does not allow to identify folders where all these items are located (without manual mouse hovering). The problem here is not only in short name only mode for folders because they use the same mode as files (and it's hard to identify folder only by it's name if it is located deep in folder hierarchy). Additional problem on the second screenshot is that folders are not shown at all! Files with their short names are shown, but folders are completely hidden. For example, in Unison folder path/name is always shown and it is shown only once for each sequence of files from the same folder (and files from this folder are additionally tabbed for convenience) - no textual garbage (repeating long paths that are absolutely the same) and no filename truncation (files from the same folder are shown without any paths, only with tabbing).

[Musenka]

I should say that FreeFileSync is quite an interesting sync application that is feature rich, customizable and well comparable with Unison that I know very well. But I cannot find convenient visual representation for syncing deep folder hierarchies with nesting levels over say 10 or more. I explained these problems in previous posts and gave some suggestions.

Maybe you can describe convenient visualization method using existing options and feature? Maybe I miss something in FreeFileSync usage pattern? I always used Unison so all my comparisons are connected with it and it's usage pattern.

[Musenka]

Dear FreeFileSync community, I cannot believe that nobody faces the same or much similar differences view problems for folders with deep nesting like user home folder, etc.!

It's obvious that current representation produces either too detailed full names (with path) with truncated filenames (the most essential part!) or too short plain filenames list without folder identification (depending on sync case folder is not shown at all / shown without path) requiring manual hovering with mouse to see tooltips.

I really cannot understand how do you solve this very basic, fundamental representation issue. That's why I proposed to make differences view a bit more customizable - with minimal modifications of the current scheme.

[xCSxXenon]

No issues with the current display for me. Your suggested display looks confusing to me

[Musenka]

May be you do not face long paths in your synchronizations and that's why current representation is quite comfortable for you?..
For example, consider some very deeply nested subfolder in your sync directory and many modified files inside this folder.
I think that any representation setting will not give comfortable results:
1. With full paths setting, there will be much repeating garbage with fully qualified path to each modified file. Moreover, aligning will be not comfortable: full string "filename with full path" is not shifted to the left to make filename visible, but just truncated from the right possibly hiding filename itself (which is hte most important part of the string).
2. With short name setting, it's impossible to identify deeply nested folder under consideration without mouse hovering and examining tooltip text. You will see only plain filenames without any folder hint.

If multiple deeply nested folders with many modified files are considered - things go worse and all representations are not comfortable. And separating representation settings for folders and files will improve things, especially with additional fixes I mentioned before (but even without them).

Of course if you do not deal with such usecases you will not see the preblem here.

[Zenju]

Very interesting ideas, Musenka! The Unison representation has very little redundancy, but is far from perfect. It's hard to make out the hierarchical relation between files and folders visually, and the different indentation for the second and following items of a folder are misleading. But maybe we can fix that.

Here's an example listing from FreeFileSync:

1.png (11.96 KiB) Viewed 10847 times

Stripping out the redundant information and adding some grouping gives:

3.png (9.59 KiB) Viewed 10847 times

Here's an even cleaner representation:

2.png (9.9 KiB) Viewed 10847 times

The "price" of the last optimization is added horizontal space. An alternative price could be adding virtual parent folders instead (even though they might be excluded with the current view filters), but that would cost extra vertical space.

Maybe the clarity alone is worth these costs? Perhaps there is some way to get some additional horizontal space by (partially!) merging left/right representations. However, we need to retain the ability to select left/right items!

Other ideas, improvements?

[Zenju]

More narrow variant: (added space: only 1 pixel per path component)

4.png (9.83 KiB) Viewed 10846 times

[Zenju]

If folder is involved:

5.png (10.04 KiB) Viewed 10842 times

The relative large indentation of the folder's child items would allow for a nice mouse-hover:

6.png (10.92 KiB) Viewed 10842 times

[Plerry]

Saving horizontal space at the cost of vertical space, an option could be

FFSfileStructureOption.png (8.12 KiB) Viewed 10834 times

This would even allow to also show the size of all contents of directories.

[Musenka]

If you ask me I would prefer saving horizontal space at the cost of vertical space of course. I can list the following reasons (all of them make sense for deep folder hierarchies only - and that is exactly my usecase):

1. There are many items in vertical direction forming some long list with scrollbar. Adding more entries (virtual parent folders or something like that) to this long list does not change anything essentially. Already long vertical list becomes a bit longer - who cares?

2. 1D vertical only navigation is more convenient than 2D vertical (items in the list) + horizontal (long entry for deeply nested item) navigation. If long entries are just truncated instead of horizontal navigation - it's not good for deep hierarchies (requires too much mouse hovering).

3. Most compact form with minimal horizontal tabbing may be used in such way that even level 10 and deeper nested items will be easily visible without horizontal scrolling and without truncation (at the cost of vertical space).

4. Duplication of identical information (the same long path for many items) is minimized (as compared to the current representation).

So if I am suggested to choose the best of demo figures from this thread, I would choose Plerry's one (Saving horizontal space at the cost of vertical space, an option could be).

[xCSxXenon]

Those experimental visuals look really good actually! The large indentation allowing for the full path to display via hover is really neat

[Musenka]

I propose the following very simple (and may be slightly extreme) self-verification of any experimental representation variant.

Just assume you are working at base nesting level 10 and considering several level 11-12-13 subfolders with several items requiring sync inside these folders. Assume that folder names are long enough to fill even very wide horizontal space with path data. And try to imagine your representation visually for this condition.

I think the only one experimental representation that will stand this extreme test is Plerry's one (Saving horizontal space at the cost of vertical space) - if tab size is really small (2-4 spaces per tab). All other representations will be broken (absolutely not comfortable: truncated / require mouse hovering / require horizontal scrolling in addition to vertical scrolling / etc.).

[Zenju]

Saving horizontal space at the cost of vertical space, an option could be
FFSfileStructureOption.pngThis would even allow to also show the size of all contents of directories.

That's essentially the "Overview panel", isn't it?

[Plerry]

> That's essentially the "Overview panel", isn't it?
Sort of.
The "Overview panel" may perhaps serve that purpose if that panel would automatically expand the branch of the file that is being selected in the (left or right) Compare result panel.
And when another file is selected there, expand that files's branch and collapse the branch for the previously selected file.
Is that something that could work for you, Musenka?

Obvious challenge: how to deal with multiple selected files in the Compare result panel.

[Musenka]

> That's essentially the "Overview panel", isn't it?

Yes, it looks like existing Overview panel, but with all functionality, sync direction icons, etc. currently available in Compare panel(s). It would be nice to have such visual representation as some option(s) for main Compare panel(s). For example, as another alternative view mode in addition to Full Path / Relative Path, etc.

> Is that something that could work for you, Musenka?

I am afraid that Overview panel functionality and visual representation is too limited as compared to Compare panel(s). Look at sync direction icons, for example. May be it's better to keep Overview panel as it is now and add new representation for main Compare panel(s) preserving all their functionality and style.

And intensive navigating between small Overview panel in lower left corner (to select branch) and Compare panel(s) to work with branch contents looks not comfortable imho.

As to me, I would prefer just new optional style for Compare panel(s) with most compact horizontal filling without touching Overview at all...

[Zenju]

Here's a beta version of my previous design that doesn't save horizontal space, but gets rid of the redundant path components:
https://www.mediafire.com/file/x5et9t9chi8qeb4/FreeFileSync_10.25_%5BBeta%5D_Windows_Setup.exe

It currently looks like this:

1.PNG (14.97 KiB) Viewed 10566 times

[Musenka]

Sorry, I'm a GNU/Linux user so I cannot verify your beta design on my specific files, because you attached Windows version only.

But I guess my long paths will keep too long and truncated because horizontal space is not saved in your new design yet. Compressing empty space (long tabs on nested levels) into just 1-2 spaces would solve this problem.

If you introduce these changes into GNU/Linux version I can provide you withscreenshots illustrating application of your new design to my files.

[Musenka]

I see that FreeFileSync 10.25 has been released and it seems to solve (at least partially) some problems described in this thread as far as I understand:
- New file tree layout for main grid
- Prioritize item name rendering if lacking horizontal space

I'll try this version (for Linux) on my real sync data with long paths...
Thanks!

[VladimirII]

Musenka
For the version before 10.25, did you see you can change the size of the columns? Regardless of the text garbage from path every truncation of file name can be eliminated with that.
What Zenju now did is, just replacing the pathname with white space without reducing the horizontal space needed and introducing an right to left alignment that is mixing at which position/pixel a filename begins.
A total mess now, thanks.
The spaceing 'Unison' does is fine, also the example Plerry posted. But not what Zenju implemented.

Some examples. Mainly from 3.0 to XP
https://www.google.com/search?q=explorer-tree-view&client=firefox-b-d&source=lnms&tbm=isch&sa=X&ved=2ahUKEwizvM2r5dvqAhWBxMQBHT_EDTQQ_AUoAXoECBIQAw&biw=1599&bih=826

Also how is Regedit.exe showing the registry? That´s a nested tree.

I immediadly disagree to your "cleaner representation: " (2.png) suggestion.

For the place to show full filepath also regedit could be the inspiration. There it is in the bottom statusbar. For FFS above the columns would be a possible place. Or the first line is always the full path and no file.

"If you ask me I would prefer saving horizontal space at the cost of vertical space of course." wrote Musenka and all who are rolling back to 10.24 I can say agree with that.

Zenju:"That's essentially the "Overview panel", isn't it?" No, because the overview contains only folders. Perry´s example contains all the folders and files as the regular compare view.

"beta version of my previous design that doesn't save horizontal space" Fine, but the alignment also changed and is not intuitive.
Problem, name truncated, first I do try is adjusting column size. Because in total differnet situations in other software it is the same way to do. Example TaskManager, especially before the new design.
Problem, files are not aligned in a row under each other, reaction: what the fuck is happening?. No immediate idea of solution, start to google. Go crazy or whatever.

[VladimirII]

With other syncs/systems nearly no file is in his row.
Folder the other way round is truncated if to long file is in first row.

After reading this thread (From the naming not related to the problem thus it is the reason) moving the column size does change the alignment. How it looks is obscure and needs explanation to handle it

[Musenka]

Unison vs FFS 10.25 (linux) Case 1 (various representations):

Screenshot_20200721_125357.png (72.08 KiB) Viewed 9627 times

Screenshot_20200721_125540.png (156.5 KiB) Viewed 9627 times

Screenshot_20200721_125859.png (160.12 KiB) Viewed 9627 times

[Musenka]

Unison vs FFS 10.25 (linux) Case 2 (various representations):

Screenshot_20200721_130139.png (154.59 KiB) Viewed 9627 times

Screenshot_20200721_130302.png (180.25 KiB) Viewed 9627 times

Screenshot_20200721_130336.png (173.69 KiB) Viewed 9627 times

Screenshot_20200721_130651.png (165.18 KiB) Viewed 9627 times

Screenshot_20200721_131032.png (123.23 KiB) Viewed 9627 times

[Musenka]

I do not see problems with Column Size and filename alignment. "Prioritize item name rendering if lacking horizontal space" works as expected. Of course, horizontal space is not saved in any way in new layout, but at least textual path-related garbage is removed and filename is showed even for long paths. So I think that there is some representation progress here.

Looking at screenshots set 2 and comparing with Unison I found that it uses quite simple thing to save horizontal space independently from sync direction. In fact it uses relative paths mode and shows relative path ONLY ONCE! The same relative path for left and right locations is named simply as "Path" and it is NOT doubled for left / right "panels" (there are no panels in Unison). Just look at the screenshots.

[Musenka]

Considering Case 2 when there are BOTH active sync directions: left to right and right to left we see that all representations demonstrated on screenshots become a bit inconvenient. I think when Relative Paths mode is selected for both left and right panels it would be natural and more convenient to see some single universal "Relative path" record which is the same for left and right panels. Or at least there should be no empty folder names for opposite sync directions: using relative path for left and right panels should show the same relative path (not empty!) thus eliminating the need to visualize relative paths twice (for both panels at the same time). So I can use Relative Path mode for any panel (A) and Item name mode for another panel (B) and relative paths will be convenient for both sync directions (no empty records sending us to examine path on another panel as it is now). Sounds complicated but look at all these screenshots and some ideas for improvements arise at once.

In any case, representation seems to be improved IMHO. Possible further improvements:
1. Save horizontal space (discussed before).
2. Elimination of duplicating relative path data on both panels (either by using shared "Path" for both panels as in Unison or by showing all necessary path data without empty lines in Relative Path on any panel, so another panel may be safely switched to Item name mode).

[Musenka]

I performed more experiments with real data and would like to thank Zenju for good work on representation issues. In fact when I close Overview and Configuration windows, switch one panel to "Relative Path" mode and another panel to "Item Name" mode and shift panels separation line to the right I obtain very good results.

The only thing I cannot understand: why detached Configuration window is not scalable?! It' s so small when it is detached that working with it is a pain (at least on Linux). And detaching is required to save horizontal space and be able to quickly show/hide Configuration window using menu.

[Musenka]

Screenshots.
The most convenient representation for my data:

Screenshot_20200721_154502.png (210.73 KiB) Viewed 9593 times

Why detached (floating) Configuration Windows is not scalable?

Screenshot_20200721_154615.png (23.17 KiB) Viewed 9593 times

[Zenju]

switch one panel to "Relative Path" mode and another panel to "Item Name" mode and shift panels separation line to the right I obtain very good results.

This might even be the best representation for FFS! Parent path information is completely redundant, but item detail info is not (item might exist only on one side, or there may be differences in size, modtime, or file name case).
The only reason why this view is not the FFS default is that it's not symmetric. IOW it just doesn't look good...

Why detached (floating) Configuration Windows is not scalable?

This seems to be a bug (on Linux). It works on the other platforms. TODO

[Zenju]

PS: I'll be releasing FFS 11.0 either later today (if all goes well) or tomorrow. The file grid has been completely overhauled, solving almost all issues that came up after the 10.25 tree view update. I've posted an update on this thread: viewtopic.php?t=7397#p25342