There are reasons why it will be difficult to write a GUI for rsync: 1. The 80% use case for rsync is a carefully crafted pre-set script that runs in a crontab

There are reasons why it will be difficult to write a GUI for rsync: 1. The 80% use case for rsync is a carefully crafted pre-set script that runs in a crontab, not as a one-off thing that you select options for and hit "run". 2. There are so many switches and options that you're not going to be able to model them all in a coherent manner without overwhelming the user. 3. The price of failure is data loss, which means that people will either be afraid to use it, or foolishly lose data and then be afraid to use it. A dry-run mode helps, but is not a panacea. What you need is a multipart system: 1. A set of vetted recipes with good, succinct descriptions of what they do, why they're useful, and where the cliffs are, and a program to apply them for the specific user. 2. A design GUI that helps guide you through the process of building your own recipes. 3. A runner for running your recipes from the command line, so you can crontab it (if the recipe system doesn't generate self-contained executables - scripts or whatever - that you can just call directly). 4. A runner for running or testing your recipes in a GUI environment, for the 5% of times you actually need this. Trying to mix more than one of these parts into a single program is a UX mistake.