> our computers are already bloated, therefore it's okay to make them more bloated
No. Don't do this. The only reason it's not already a problem is that most apps still aren't Electron.
Rsync, GUIs, power, control, design, and decisions
91–100 of 138 posts
Re: Rsync, GUIs, power, control, design, and decisions
#92If ever there was a tool that didnt need a gui its rsync. Idea is to keep two folder structures in sync. Exactly the sort of thing you want to script, or trigger when one side changes, or cron. I've use rsync all my computing life but i've rarely wanted to have to manually push a button to make it work. A good cli interface is clearly the correct interface to rsync. Embeding rsync in an app that does something else m…
I think the foundation of this comment is incorrect. This helps you build up the rsync command and test it. It gives you the rsync command that it runs. You're supposed to take the command it generates and use another tool to automate it. You're not supposed to automate the interface. It fulfills the conditions you expect of it. And personally, I loath constructing rsync commands. Every 2 months I have to parse that…
And if the tool has an option to say "yes, that's what I needed, now make me a crontab entry!" then I'd say it could be very useful.
As the parent mentioned I script rsync once I know what I need. But like you said I do it so infrequently I usually have to man rsync to find the right cl to add to my script.
Re: Rsync, GUIs, power, control, design, and decisions
#93If ever there was a tool that didnt need a gui its rsync. Idea is to keep two folder structures in sync. Exactly the sort of thing you want to script, or trigger when one side changes, or cron. I've use rsync all my computing life but i've rarely wanted to have to manually push a button to make it work. A good cli interface is clearly the correct interface to rsync. Embeding rsync in an app that does something else m…
Very few people "know" rsync's interface. Any time I want to do anything more than -avz, I have to look it up. A well-made GUI would mean that instead of looking up "what option or combination of options does this?", you could just find the label that says "does this".
Of course, this GUI seems to only have the few most common options (i.e. the ones people are likely to remember), which indeed makes it pretty useless.
Re: Rsync, GUIs, power, control, design, and decisions
#94> People don’t care that an application is a streamlined 3MB or a big round 200MB boy
At the risk of beating this topic to death here on HN...Some people care; I know I do. I think the audience for rsync would care more than a nontechnical user, for sure. If I downloaded a program with an extremely basic UI that essentially is a string builder, I probably wouldn't bother if the final executable was over, say, 10MB. My preference would be to hack together a basic CLI menu that could do the same thing and I can stick it in a folder that contains a bunch of other scripts.
Am I the target audience, or even close? Probably not, but I don't know many people who want what rsync offers who aren't programmers.
From the linked ServerFault page asking why Windows users don't use rsync:
> I would say that rsync is just too freaking complicated. Anyone I know who uses it regularly has a pre-set group of flags that generally does what they want.
This is followed by more reasons Windows users can't handle or don't want a CLI, along with a few mentions of Robocopy on Windows. Which, honestly, is the reason I don't use rsync on Windows. Windows (both Desktop and Server) ships with Robocopy, not rsync. To run rsync, I'm (or rather, was until WSL) forced to use a Cygwin-like environment to run it, which is overkill unless you're already using an environment like that (i.e. not on a Windows Server instance, most likely).
Re: Rsync, GUIs, power, control, design, and decisions
#95If ever there was a tool that didnt need a gui its rsync. Idea is to keep two folder structures in sync. Exactly the sort of thing you want to script, or trigger when one side changes, or cron. I've use rsync all my computing life but i've rarely wanted to have to manually push a button to make it work. A good cli interface is clearly the correct interface to rsync. Embeding rsync in an app that does something else m…
I think the foundation of this comment is incorrect. This helps you build up the rsync command and test it. It gives you the rsync command that it runs. You're supposed to take the command it generates and use another tool to automate it. You're not supposed to automate the interface. It fulfills the conditions you expect of it. And personally, I loath constructing rsync commands. Every 2 months I have to parse that…
I appreciate this comment, because at first I didn't understand why I would ever use this program, and now I want to use it. Rereading 'man rsync' for the 10th time is really is annoying.
But it just will never be worth a 200mb download. Gosh. It's like bloat on a whole 'nother level.
Re: Rsync, GUIs, power, control, design, and decisions
#96Earlier quoted context omitted.
It is a problem. Here's [1] a talk from fossdem on the various issues, and a couple solutions. [1]: https://youtu.be/ANcU1g7ZWdU
It seems to me, that the issue here is mostly web developers who are used to coding for browsers, are slowly moving into the desktop application domain, and instead of them applying the traditional languages used there (C and C++), are circumventing these by creating frameworks that allow them to continue using their web langs in a desktop environment. If that is the case... they'll never get rid of the megabyte bloa…
I think the central problem with native UI is how much better looking web-based UIs are, and the talk I cited spends time making this point. HTML/CSS/Js built UIs have much better, modern, reactive styling options & when done properly, look much better than, say GTK.
I'm personally a huge proponent of C and would love to have access to WebApis [1] via Webassembly. That would still necessitate a runtime capable of interpreting HTML/Css into views, but projects like webview [2] have demonstrated that this access needn't come at a huge cost. For instance, in [3], for a UI in HTML/CSS with business logic in C, system resources clock in at [RAM: 6MB, CPU: 1.3% Storage: 10MB], which is completely reasonable.
[1]: https://github.com/WebAssembly/webidl-bindings/blob/master/p...
[2]: https://github.com/zserge/webview
[3]: https://fosdem.org/2019/schedule/event/godesktopapps/attachm...
Re: Rsync, GUIs, power, control, design, and decisions
#97Earlier quoted context omitted.
It seems to me, that the issue here is mostly web developers who are used to coding for browsers, are slowly moving into the desktop application domain, and instead of them applying the traditional languages used there (C and C++), are circumventing these by creating frameworks that allow them to continue using their web langs in a desktop environment. If that is the case... they'll never get rid of the megabyte bloa…
I think the central problem with native UI is how much better looking web-based UIs are, and the talk I cited spends time making this point. HTML/CSS/Js built UIs have much better, modern, reactive styling options & when done properly, look much better than, say GTK. I'm personally a huge proponent of C and would love to have access to WebApis [1] via Webassembly. That would still necessitate a runtime capable of int…
Wow, thanks, those resources will hopefully keep me busy later... I'm building a cross-platform C engine, and had the usual suspects of "Windows, Linux, maybe Mac", but then recently also "discovered" this ancient FastCGI technology, and just day or two ago skimmed the WebAssembly wiki, and I'd like to explore possibilities of implementing my engine in web applications, too, afterwards.
But if I understand WebView correctly, wouldn't this be HTML in C/C++, i.e. is WebView... "just" a browser? Or... is it "just" spawning a minimal OS-Window on the target system with a system-built-in browser engine? For my intents and purposes, that's kinda the reverse of what I'm aiming for with my C project, which rather would be to bring sprites and raw data formats to your browser window.
In essence, what I meant with "reversing everything with C" is basically programming webpages like C programs. Taken to the extreme, what I mean is for example compiling Windows to run in a browser-context instead of a physical x86-PC.
Re: Rsync, GUIs, power, control, design, and decisions
#98I really wish there were more GUI wrappers that literally wrote the CLI commands out on screen as the GUI was modified, to help with bridging the GUI/CLI gap for people. Also, I miss arRsync.
For what its worth this is what a lot of CAD and EDA tools are doing (Autocad, Vivado (Xilinx), Cadence etc.)
Re: Rsync, GUIs, power, control, design, and decisions
#99> 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…
> There should be some sort of logical grouping. One area of the screen would be options related to what is transferred, a second area is metadata, the third one is speed-only optimizations, fourth is logging and so on. Having "hardlinks" all the way on the left and "symlinks" all the way on the right does not make a good GUI. This is exactly what Microsoft have done with its ribbon interface[1] which is actually a m…
I think I would mind //graphical menus// less than the change to an always in your face ribbon.
What I loved most about the seriously ancient UIs, way back in the Win 3.x days and forward, was that not only were the options categorized, they also had prominently displayed (right justified instead of left) the keyboard shortcut you could memorize if you knew you were doing it frequently. Yes, that sort of still exists, but you have to go out of your way to do something extra to see it: these days you have to tap a modifier key while in the focus area of the menu.
Re: Rsync, GUIs, power, control, design, and decisions
#100Earlier quoted context omitted.
I think the foundation of this comment is incorrect. This helps you build up the rsync command and test it. It gives you the rsync command that it runs. You're supposed to take the command it generates and use another tool to automate it. You're not supposed to automate the interface. It fulfills the conditions you expect of it. And personally, I loath constructing rsync commands. Every 2 months I have to parse that…
I appreciate this comment, because at first I didn't understand why I would ever use this program, and now I want to use it. Rereading 'man rsync' for the 10th time is really is annoying. But it just will never be worth a 200mb download. Gosh. It's like bloat on a whole 'nother level.
Interestingly, the useful parts (for you, and likely lots of others) are those that would be readily adapted to a regular web app/site.