Only compare automatically

[coolname]

Hello,
I am enthousiastic about this app. But wonder whether it is possible to
automatically already start the compare whenever a conf. file is loaded (or
freefilesync is started with a conf. file). Or do only the compare job in a
batch process, instead of also already start the sync itself.
To automatically start the compare is never a problem for me (and probably a
lot with me), as nothing is changed yet anyhow, so this saves time and manual
clicking. However, I would really like to look at the result befor the app.
starts to copy, delete, overwrite files.
thanks

[Zenju]

Technically this is possible for sure. But I think the main point here is a
tradeoff between usability and functionality.
Main question is: Is there a way to integrate this functionality in a lean way
without degrading overall usability, i.e. is it worth an extra
checkbox/button?

[coolname]

Thanks for the respond. To my opinion the answer would obviously be yes. It
could be added as checkbox indeed in either the global setting or in the batch
setup screen. In the latter case in can be selected per individual batch job,
hereby not complicating the general user interface for -simple- users, who
will probably not use the batch mode to often anyhow.
I user to use the non-free Filesync software in the past. And actualle the
FreeFileSync is better in every aspect, exept this option (which was in there,
just as an option one could check as a general setting, not complicating
things at all).

[Zenju]

I'm just thinking: The functionality you describe seems to be really handy.
But there are occasions where an automated comparison does not fit: 1. When
FFS is started "as is", i.e. implicitly loading LastRun.ffs_gui. I assume In
most cases the user just wants to change directories first before starting the
process. 2. If either of the directories is not existing. In this case the
user would be faced by an error message each time, without having the chance
to correct any of the paths.
Sure: 1 and 2 could be "solved" by offering a (global/local) checkbox to turn
instant-compare on or off. But maybe we don't need it? What if FreeFileSync
ALWAYS does a comparison immediately in GUI-mode except cases 1 and 2?

[coolname]

hmmm, I think you are absolutely right when I think of it. Indeed, in those
two cases, one would not want it, but in any other case most probably yes
indeed! There is maybe another (more rare) exception: if someone has a custom
made ffs_gui file, but wants to alter it for some reason before comparing. I
think it would be very intuitive if one sees that comparing starts
automatically, but just has to press the Abort button to halt that process.
So, yes, I think your solution will most probably also work just great!

[aiadi]

I would rather, to be honest, click on "compare" to start the process rather
than "Abort" one that has started already. If I understand it clearly then
your request is well catered for using the batch mode anyway. To minimise
clicking one option would be the ability to compare and synchronise at the
same time (for example by only clicking "synchronise") for those who wish to
skip the comparison stage.

[Zenju]

The request is not for FFS's batch mode (i.e. *.ffs_batch files) but for
starting FFS in gui mode (== double-clicking on/or loading*.ffs_gui files)
The usecase is that the user wants to get a full preview before actually
starting synchronization. (That's slightly different than "compare and
synchronise at the same time")

Of course the suggested solution is a tradeoff:

- If I want to change an existing *.ffs_gui configuration before synchronization there is one additional button-click (abort botton)
- If I just want to load a configuration and see the sync-preview there is one button-click less. (compare button)

Generally I would say changing a configuration (*.ffs_gui) is less common than
simply using it: If this is true, this feature would be beneficial.

[coolname]

I think you are completely right in that Zenju. Normally, after setting up
configuration files, one will use them far more often that changing them.
Otherwise, the purpose of using configuration files would be obsolete for that
application I would say.

[grobbla]

Hello,

just my opinion: the main reason for me to start the GUI, is to change
something. So I need to look at the paths first, change something, then press
compare for a preview. You see, in my case, I would not want a hard coded
compare at GUI start. Compare is only one click away.

To solve this issue, what about a command line option, i.e. "-compareOnStart"
to start a compare on a given file, or the last saved state?

Additionally, the user could add a shortcut with this new parameter to the
desktop, as a drop target or to load the last saved state.

by,
fred

[Zenju]

> I would not want a hard coded compare at GUI start.

An immediate comparison when starting FFS regularly is not in discussion
anyway. Or don't you want it when double-clicking on an *.ffs_gui file
neither? I think this would be the most beneficial usecase. (similar to
double-clicking on *.ffs_batch files where sync starts right off.)

About automatic comparison when loading a config while gui already is active:
This indeed might surprise users... might be even a bad idea if warning
messages are shown like "error accessing directory X" or "initial
synchronization...".

> what about a command line option, i.e. "-compareOnStart"
FFS's batch mode started (in the early versiosn) by being completely
configurable via commandline. But the main drawbacks are lack of Unicode
support and limited length (about 250 characters). So a configuration file is
supposed to be a superior replacement. Well it is in most regards, so I don't
want to go back to commandline mode.

[Zenju]

Sum-up: Currently I consider the conditions for immediate comparison to be the
following:

1. Only when FFS is started with a *.ffs_gui file as command-line parameter (this includes double-clicks on *.ffs_gui files)
2. Except when any of the directories is not existing.

[grobbla]

> An immediate comparison when starting FFS regularly is not in discussion
anyway




Oh, I did not realize this. So, this is no problem for me at all, as I only
start the gui, then load the files I want to work with, which are mainly batch
files.



> 2. Except when any of the directories is not existing.




This is a very good idea!


regards,
fred

PS: about the reply function here: the post preview has gone, the input text
field is still too tiny, wondering how this post will look like after sending
it :)

[Zenju]

Finished implementation for v3.3!

Regards, Zenju

[coolname]

Many many thanks Zenju, for implementing this. It works great now.
(btw. sorry for not replying earlier, but I've been away for a while)

Anyway, just great. Also the way you handled this idea and discussion by the
way!!!