Hi,
In main screen, I add multiple folder pairs (it is often more intuitive than filters).
1.- Feature request: [>] (Arrange folder pair) : Add more options (with same [>] in first row)
-- Add folder pair above -- (obvious)
-- Add folder pair below
-- Duplicate folder pair -- helps for long paths to change only final subfolder
-- Disable / Enable folder pair -- (When disabled, show the path grayed )
-- Remove folder pair --(and suppress the red [-] icon to allow more space for paths)
-- Move Up
-- Move Down
2.- Feature request: central [gear] (Local comparison settings) + [gear]: (Local synchronization settings)
-- Show the same submenu options than in Main buttons
-- Add a submenu option "Settings dialog..."
3.- Resize buttons in folder pairs to allow more space for paths
-- Change large "Browse" button by tiny "..." button
-- Reduce large "Cloud" icon
-- Suppress the "[-] (Remove folder pair)" icon, it appears inside [>] (Arrange forlder pair) submenu
I guess that those simple changes will improve the usability of the interface.
Cheers. Best regards for all.
Feature - Improve UI of the folder pairs
- Posts: 3
- Joined: 16 Oct 2020
-
- Posts: 4290
- Joined: 11 Jun 2019
I do enjoy your first set of suggestions. I have definitely found myself juggling around paths to order them in a more concise way. Adding pair above/below would be sweet
- Posts: 2
- Joined: 19 Nov 2024
I also vote for move up/down.
I also wanted to organize my paths more than once.
I also wanted to organize my paths more than once.
-
- Posts: 2613
- Joined: 22 Aug 2012
Be aware that any re-ordering of your left-right folder pairs would be only good for your own insight/overview.
The order in which files are actually synced by FFS has no relation to the sequence in which your folder pairs are listed.
The order in which files are actually synced by FFS has no relation to the sequence in which your folder pairs are listed.
- Posts: 3
- Joined: 21 Nov 2024
@The order in which files are actually synced by FFS has no relation to the sequence in which your folder pairs are listed.
Is that so? The sequence of commands executed is not guranteed to be same as the sequence of folders pairs?
If not - then the UI is unnecessary contra intuitve and the concept of folder-pair dependencies - aka first things first - makes no sense. Parallalizing ALL folder pairs has a strange feel.
Is that so? The sequence of commands executed is not guranteed to be same as the sequence of folders pairs?
If not - then the UI is unnecessary contra intuitve and the concept of folder-pair dependencies - aka first things first - makes no sense. Parallalizing ALL folder pairs has a strange feel.
- Posts: 2
- Joined: 19 Nov 2024
Yes, it is cosmetic and yet I would like to be able to group things to be sure that I am not missing anything.Be aware that any re-ordering of your left-right folder pairs would be only good for your own insight/overview. Plerry, 20 Nov 2024, 09:02
Sometimes new items are added and I would like to move them to the group they belong.
-
- Posts: 2613
- Joined: 22 Aug 2012
@Martin Zvieger
FFS determines all sync actions at the end of the Compare phase, and executes those sync actions during the Synchronization phase.
If you have a location pair A => B and a pair C => D, at the end of the Compare phase FFS has planned all actions to make A and B to become in sync and all actions to make C and D to become in sync.
As long as there is no overlap between your sync locations, the sequence in which those sync actions are executed is irrelevant, and hence the sequence in which the location pairs are listed is irrelevant to the functioning of FFS and just, as ertank words it, cosmetics..
If there are one or more overlaps between your sync locations, FFS warns you about that and warns you that you might get unexpected sync results.
e.g. if your location pairs are A=>B, and B=>C, files synced A-to-B are not yet or not updated yet on B during the B=>C Comparison, and thus will not result in B=>C sync actions during the present sync.
Even not if A=>B is listed before B=>C.
FFS determines all sync actions at the end of the Compare phase, and executes those sync actions during the Synchronization phase.
If you have a location pair A => B and a pair C => D, at the end of the Compare phase FFS has planned all actions to make A and B to become in sync and all actions to make C and D to become in sync.
As long as there is no overlap between your sync locations, the sequence in which those sync actions are executed is irrelevant, and hence the sequence in which the location pairs are listed is irrelevant to the functioning of FFS and just, as ertank words it, cosmetics..
If there are one or more overlaps between your sync locations, FFS warns you about that and warns you that you might get unexpected sync results.
e.g. if your location pairs are A=>B, and B=>C, files synced A-to-B are not yet or not updated yet on B during the B=>C Comparison, and thus will not result in B=>C sync actions during the present sync.
Even not if A=>B is listed before B=>C.
- Posts: 3
- Joined: 21 Nov 2024
Thanks for the insight. The subject matter we are discussing is intra-application job scheduling.
Begs for a feature request. Lets call the established modus operandi "full parallelization".
Obviously this places restrictions on the commands executed after the sync actions. Never ever assume a dependency. Period.
Lets call an alternative modus operandi "sequenced parallelization". A => B , B => C would work. Post syncing commands are executed in the order listed. And we can build upon the intended dependency.
The bigger picture. Afaik no syncing software is particularly good in syncing containers. In the age of Virtual Machines and Container Files (vhdx, vdi, iso, 7z, etc) we are now, there is considerable room for improvement.
Do we want to sync the container file - yes we do, sometimes. Or do we wan't to sync the content of a container file. (Attach/Mount -> Sync -> Detach/Unmount). Yes we do, more often then not one would assume. I envision a plugin architecture for each type of container. A demanding container type are Microsoft Outlook *.pst files which can be large. Specialty software exists but not to widely used - for reference: https://www.sync2pst.com/
The UI-Logic shsall be similary to link handling - copy link as is versus copy linked to stuff.
So the order of commands has great value. Trading value for minor changes - deal?
Begs for a feature request. Lets call the established modus operandi "full parallelization".
Obviously this places restrictions on the commands executed after the sync actions. Never ever assume a dependency. Period.
Lets call an alternative modus operandi "sequenced parallelization". A => B , B => C would work. Post syncing commands are executed in the order listed. And we can build upon the intended dependency.
The bigger picture. Afaik no syncing software is particularly good in syncing containers. In the age of Virtual Machines and Container Files (vhdx, vdi, iso, 7z, etc) we are now, there is considerable room for improvement.
Do we want to sync the container file - yes we do, sometimes. Or do we wan't to sync the content of a container file. (Attach/Mount -> Sync -> Detach/Unmount). Yes we do, more often then not one would assume. I envision a plugin architecture for each type of container. A demanding container type are Microsoft Outlook *.pst files which can be large. Specialty software exists but not to widely used - for reference: https://www.sync2pst.com/
The UI-Logic shsall be similary to link handling - copy link as is versus copy linked to stuff.
So the order of commands has great value. Trading value for minor changes - deal?
