Tcl/Tk is much a better choice of a toolkit for this job.
Rsync, GUIs, power, control, design, and decisions
61–70 of 138 posts
Re: Rsync, GUIs, power, control, design, and decisions
#62> Is it better to make up common rsync “recipes” for people to use, or is it better to let folks have access to ALL of the flags [...] and pick’n’mix what they want? I think both. This is the hard part about GUI design -- it is pretty easy to make a list of 100 command-line options listed alphabetically on the man page, but for GUIs, people expect much more. There should be some sort of logical grouping. One area of…
I would think there maybe a "command-line" version of GUI design: supply limited default buttons for common options, but allow user customization. For example, I would love to have the button from author's design but tune it specifically to my need including running a specific set of "command lines".
If you have some common sets of options (and pipes and so on), then I think shell scripts (and shell aliases) can be used for that.
Re: Rsync, GUIs, power, control, design, and decisions
#63> People don’t care that an application is a streamlined 3MB or a big round 200MB boy Assuming all else to be equal (UX, functionality, etc), people will absolutely gravitate towards the [5MB storage, 20MB RAM, 0.5% CPU] combination to electron's [300MB storage, 200MB RAM, 5% CPU], especially when they are running multiple such programs. But, what electron offers is getting from zero to product across all desktop OS-…
This is actually an issue in app development? I thought with SDL, QT, wxWidgets, et al., writing native apps was basically a covered topic...?
Re: Rsync, GUIs, power, control, design, and decisions
#64I agree with the other users who have a pre-set of options that work for them. I have used -avzP for 99% of my Rsync uses over a decade and a half (exceptions being adding -e ssh or refactoring for backup solutions). By putting all the options in an 'options menu', keeping the defaults sane, and check boxes off the screen, you end up with a much simpler and easier to use tool.
Re: Rsync, GUIs, power, control, design, and decisions
#65Earlier quoted context omitted.
I don't like the --no-h change they made to the --progress format (mentioned in another comment) because it broke my parsing once, but otherwise I don't really see a problem with it and I expect most people have never tried to parse it. What's so bad about --progress? Edit: --progress also tells you how many files rsync has been told to sync, and of those, how many are remaining. 2384908 100% 57.52MB/s 0:00:00 (xfr#1…
--progress gives you only the progress of individual file transfers.
--info=progress2 actually gives you the progress of the whole transfer (but I don't think you can do both). You can use --info=name0,progress2 if you don't care about individual files scrolling the terminal.
Re: Rsync, GUIs, power, control, design, and decisions
#66I recommend also trying Grsync (released in 2005), which is mostly the same thing and is available with multiple languages support. http://www.opbyte.it/grsync/
Re: Rsync, GUIs, power, control, design, and decisions
#67Earlier quoted context omitted.
If the tldr entry exists. Obscure commands don't have one while you're less likely to know these well. Chicken/egg problem.
In my experience the coverage is shockingly good. And if you find a case where there is no tldr, you're back where you're started having lost not more than five seconds. The failure case is graceful, so it was easy to put tldr into my workflow.
I wonder if tldr returns a meaningful exit value that you could write an alias/function for something like tldr $term || man $term
Re: Rsync, GUIs, power, control, design, and decisions
#68> People don’t care that an application is a streamlined 3MB or a big round 200MB boy Assuming all else to be equal (UX, functionality, etc), people will absolutely gravitate towards the [5MB storage, 20MB RAM, 0.5% CPU] combination to electron's [300MB storage, 200MB RAM, 5% CPU], especially when they are running multiple such programs. But, what electron offers is getting from zero to product across all desktop OS-…
This is actually an issue in app development? I thought with SDL, QT, wxWidgets, et al., writing native apps was basically a covered topic...?
It is a problem. Here's [1] a talk from fossdem on the various issues, and a couple solutions.
Re: Rsync, GUIs, power, control, design, and decisions
#69Nothing beats a good CLI with a proper man page in my book. I like having all the power at my fingertips, and a good way to search for what I want to do without using the internet.
When reading a man page, especially a classic man page like the ps man page or maybe a system call man page like sigaction , I try to keep in mind that the information is there but may require careful study. Good man pages are a often quite terse, requiring attentive reading. I like using man the best, but there are two other methods that command-line programs can use to provide documentation, GNU's info and built in…
I also like `tldr ` if a cached version of the internet's advice is needed.
Last resort is Google.
Re: Rsync, GUIs, power, control, design, and decisions
#70Nothing beats a good CLI with a proper man page in my book. I like having all the power at my fingertips, and a good way to search for what I want to do without using the internet.
"proper" man page is quite the qualifier. (Edit: as in, I know I'm "supposed" to use man pages, but it's almost easier to google for it. The man pages I've seen aren't as easy to use for common cases). CLIs are much more limited at discoverability compared to a graphical interface (TUI/GUI) which can show you all the options and let the user directly interact .
Install `tldr`.