Bug: Drag & Drop Header Text Changes

[Polychronopolis]

I'm a relatively new FreeFileSync user, so I do not know if this issue is expected behavior or if this occurs in previous versions. I'm using donation version 14.3 on both Windows 10 and Ubuntu 24.04.2.

Windows 10:
When entering a folder path, the 'Drag & Drop' header text will dynamically change. If the folder path does not a properly formatted path, the header text changes to the executable's parent folder path with the text from the field appended.

Win10_InvalidPath.jpg (11.81 KiB) Viewed 56125 times

Once the text meets a path format, the header changes back to 'Drag & Drop' unless the path uses an environmental variable. When a variable is used, the header text changes to the full path referenced.

Win10_VariablePath.jpg (11 KiB) Viewed 56125 times

Ubuntu:
I'm less familiar with Linux but the header behaves similarly. If an invalid path is entered, the header text changes to the user's home directory with the text from the field appended.

Ubuntu_InvalidPath.jpg (9.74 KiB) Viewed 56125 times

If the '~' alias is used, the header text changes to the full path referenced.

Ubuntu_VariablePath.jpg (10.16 KiB) Viewed 56125 times

On both systems, the application will properly compare and synchronize file paths using variables. If the header text changing is intentional, it is confusing for users as there's no clear explanation.

[xCSxXenon]

What's the issue? You're a new user and figured out that the header is expanding the variables. Anyone using variables has the knowledge to recognize this

[Polychronopolis]

If "anyone using variables has the knowledge", then why does the header text need to continue showing the expanded path?

If I enter a properly formatted path without variables, the header remains as "Drag & Drop". However, if I use a properly formatted path with a variable, it stays as the expanded path. To me, the issue is the headers inconsistency as headers are static everywhere else in the app.

Multi.jpg (86.45 KiB) Viewed 53094 times

Going further, the only time "Drag & Drop" is relevant is when setting or changing the folder path. I'd suggest replacing "Drag & Drop" with headers with 'source' and 'destination' with the ability to sort the folder pairs. The path entered can be tested using the Browse button and the ability to drag and drop could easily be conveyed with an information bubble or button. Sorting the list must be performed manually using numerous clicks or directly editing the job file.

[xCSxXenon]

If "anyone using variables has the knowledge", then why does the header text need to continue showing the expanded path?

For quick confirmation. There is nothing gained by removing it or changing it

I'd suggest replacing "Drag & Drop" with headers with 'source' and 'destination' with the ability to sort the folder pairs.

FFS doesn't have "source" and "destination" since two-way syncing is possible and very popular. However, being able to sort the pairs more easily has been mentioned here many times, and I agree. Being able to drag the pairs around would be amazing. Currently, you can click the black arrow to move them up or down.

[Polychronopolis]

There is nothing gained by removing it or changing it

I would argue that consistency and clarity improves the user experience and would have spared us from this dialog.

As the application currently behaves, the header only changes based on an [RegEx?] evaluation of the dropdown text. The evaluation partially accommodates environmental variables but lacks a trigger to return the header to its default text. Further, this behavior is only exhibited in the topmost folder pair leaving the user 'unassisted' when editing subsequent folder pairs. These behaviors did cause me a moment of confusion and I've been working in IT roles for half my life. A less experienced user may not understand the behavior.

I was leaving it up to the developer to review and determine how if and how they would implement a solution. If I were coding it, the simplest solution would be to change the header text only if the top dropdown box has active cursor/focus. Once that control loses focus, return the header to its default value. However, there are a number of more robust solutions could be implemented.

FFS doesn't have "source" and "destination" since two-way syncing is possible and very popular.

I'm familiar with two-way sync. Again, I was leaving the final decision to the developer. The product I'm migrating from uses a "Left" and "Right" but even a simple "Location" would suffice as a header.