Is 11.1 supposed to have addressed the view issue?

[JDB]

Is 11.1 supposed to have addressed the view issue?

I apologize for being negative, but ...

IT IS WORSE THAN IT EVER WAS!

What is the problem? Why not just restore the old 10.24 code and enable these new crazy whitespace views and confusing representations as options that can be selected if desired?

I contributed again to FFS because I continue to benefit from its OTHER features, and it's not fair to hold subscription fees back as ransom when there is still much to be gained from using the software. However, I think that there is some issue or problem brewing here with the reluctance to listen to the customer base. Please listen to what people are saying. That's all; I am not going to get involved in further discussion because this is all I have to say from now on.

-JDB

[JPringle]

I am sad but I must say that I agree 100% with JDB.

There has been a lot of discussion about the FFS interface here but the new 11.1 does not solve the problem and even makes it worse.
Look below, I understand even less the display of the directories with the 11.1, with the end of the directory name over the beginning !

FFS 10.24

20200904_FFS10.24.png (163.13 KiB) Viewed 2488 times

FFS 11.0

20200904_FFS11.png (152.25 KiB) Viewed 2488 times

FFS 11.1

20200904_FFS11.1.png (156.32 KiB) Viewed 2488 times

[bgstack15]

What is the problem? Why not just restore the old 10.24 code and enable these new crazy whitespace views and confusing representations as options that can be selected if desired?

The upgrade from 10.24 to 10.25 updated the layout. The upgrade from 10.25 to 11.0 switched GUI toolkits from gtk2 to gtk3. It is possible the old code is not easily adaptable to gtk3. I hope Zenju can fix it though, because a lot of us are expressing concerns about the new design. It's good to be using gtk3, but not at the expense of a harder-to-use layout.

[Zenju]

What is the problem? Why not just restore the old 10.24 code and enable these new crazy whitespace views and confusing representations as options that can be selected if desired?

Before implementing a solution, the problem needs to be fully understood. Adding options is a good solution if there are competing behaviors of similar importance which cannot be reduced any further. These conditions don't seem to be fulfilled. Are the alternatives of equal importance? Are there really two variants or can they be consolidated?

Look below, I understand even less the display of the directories with the 11.1, with the end of the directory name over the beginning !

It's interesting to note that all the screenshots lack file icons. The 11.1 design doesn't seem to work well without folder icons. So the question is: how many FreeFileSync users turn file icons off? I don't have any numbers, but would assume that most leave them enabled?

The upgrade from 10.24 to 10.25 updated the layout. The upgrade from 10.25 to 11.0 switched GUI toolkits from gtk2 to gtk3. It is possible the old code is not easily adaptable to gtk3.

FreeFileSync is still compiled against GTK2. GTK3 has made a few (insane?) design decisions. Until those are solved, FreeFileSync must stay on GTK2: GTK+ 3.6 introduced caching of widget styling information

For reference, here is how FFS 11.1 looks with file icons enabled (= the default)

icons-on.png (10.52 KiB) Viewed 2445 times

and with icons disabled:

icons-off.png (7.81 KiB) Viewed 2445 times

and here the old FFS 10.24 layout:

ffs-old.png (14.71 KiB) Viewed 2445 times

[JPringle]

It's interesting to note that all the screenshots lack file icons. The 11.1 design doesn't seem to work well without folder icons. So the question is: how many FreeFileSync users turn file icons off? I don't have any numbers, but would assume that most leave them enabled?

Hi Zenju!
That's a good point! For my part, I don't display the icons for the sole purpose of saving as much space as possible for the text (directory + file name).

[bgstack15]

FreeFileSync is still compiled against GTK2. GTK3 has made a few (insane?) design decisions. Until those are solved, FreeFileSync must stay on GTK2: GTK+ 3.6 introduced caching of widget styling information

I don't doubt that gtk3 is causing issues. But while gtk3 got weird, gtk4 is going to get worse, I hear.

I got the impression that because FreeFileSync 11.0 has a bullet point for "Start supporting GTK3 (Linux)" that you had solved the gtk3 crashing problem. Debian dropped some gtk2 libraries required for compiling FreeFileSync so I was pleased that this bullet point existed. If you are saying that gtk3 is still not ready for prime-time in FreeFileSync, I can re-activate my gtk2 compilation efforts.

[Zenju]

I got the impression that because FreeFileSync 11.0 has a bullet point for "Start supporting GTK3 (Linux)" that you had solved the gtk3 crashing problem. Debian dropped some gtk2 libraries required for compiling FreeFileSync so I was pleased that this bullet point existed. If you are saying that gtk3 is still not ready for prime-time in FreeFileSync, I can re-activate my gtk2 compilation efforts.

The issue with GTK3 crashing related to file icon loading is fixed/worked around (bummer being that GTK3 insists on rendering icons on the main thread unlike Windows, macOS - and that for an operation that can hang the main thread if the icon is located on a slow network!). This was meant with "Start supporting". GTK3 layout in general is a real mess (various incompatible styling formats depending on which minor version of GTK3 is installed), but can be hacked around.
But the issue linked above ("This cache is only updated at particular times of GTK's choosing.") is a real show stopper. Practically it means the layout of some windows is distorted and remains so until GTK3 internally decides to update its stale buffers at what seems random times. No way (that I know of) to force GTK3 to update manually. This wouldn't be much of a problem (some GUI controls are even worse in GTK3 than in GTK2, most notably the spin controls) if Linux distributions didn't stop shipping with GTK2 installed.

[Zenju]

Hi Zenju!
That's a good point! For my part, I don't display the icons for the sole purpose of saving as much space as possible for the text (directory + file name).

The most confusing element seems to be a lack of separation of item names and parent folder. The first item is "glued" together with its parent while subsequent are not, which is a remnant of the old 10.24 view. Adding a few vertical lines seems to improve the UI significantly and also simplifies the code:

grid view - no file icons.png (46.15 KiB) Viewed 2374 times

Previously:

11.1 - no file icons.png (47.29 KiB) Viewed 2374 times

[JPringle]

The most confusing element seems to be a lack of separation of item names and parent folder. The first item is "glued" together with its parent while subsequent are not, which is a remnant of the old 10.24 view. Adding a few vertical lines seems to improve the UI significantly and also simplifies the code:

First of all, the lack of separation of item names and parent folder is not confusing to me, cause its the normal way to give folder and filename in Linux.
What I see is that FFS is very good software, and many of us here really appreciate it for its excellence in file synchronisation. This must be remembered!
But the discussion on flat vs tree file structure highlights the fact that some details can be improved on the interface :

1/ Vertical lines are a good start but there are still some small details that could be improved for a better FFS. What is annoying is that the vertical separations are not aligned, which makes the whole thing messy.

20200907_Zenju_grid view with file icons_not aligned.png (53.94 KiB) Viewed 2363 times

And for that, it would be simpler to have a path column and a filename column!

2/ Even when displaying the icons, it is not natural to have the name of the last directory above the directories containing it

20200907_Zenju_grid view with file icons_directories.png (10.75 KiB) Viewed 2363 times

3/...but I see a very good idea, both for the flat and the tree view: suspension points. They allow to display the beginning and the end of the path, and the filename (which are the most important elements) while shortening the complete path if it is too long.
If there is no place enough to write the whole path, FFS should display something like :
Logiciels/Synchronisation/FreeFi[...]orum/20200806_FFS10.24_wish.png

4/ As I have already written, an improvement of the colours in FFS would make the interface more explicit (green for the files that are kept, red for those that will be deleted or updated)

20200806_FFS10.24_wish2.png (110.97 KiB) Viewed 2363 times

5/ A great improvement of 11.1 is that floating panels are now resizable for Linux users... but they always stay in foreground :-( The space gained on the main interface makes it easier to display long paths, but it remains hidden by the window in the foreground. Possible to reduce it to an icon like the logfile?

20200907_FFS_floating.png (125.96 KiB) Viewed 2363 times

Thank you Zenju for listening to users' requests, it may seem cosmetic but it is very important for the pleasure of using a software.