Live data from Hacker News

You Don't Need a GUI

github.com

411–420 of 439 posts

Re: You Don't Need a GUI

#411

Earlier quoted context omitted.

That might be more because finder is so bad and less to do with file management GUIs in general. Windows Explorer and Nautilus are both much better than finder.

Imagine using Windows Explorer... Right Click -> New Folder Choosing the files you want to move there -> CTRL+C -> Going into the directory -> CTRL+V Yeah that’s just the best and most efficient way to move files into a new directory.

Creating new folder or moving/copying files can be done in two clicks with ribbon buttons.

Re: You Don't Need a GUI

#412

Earlier quoted context omitted.

I didn't see how this could work in the general case and indeed it doesn't on dolphin. Consider this folder tree: + foo +- bar.txt + bar +- bar.txt Moving the foo/bar.txt to bar/ in Dolphin then undoing leaves you with an empty bar/

Yeah there are definitely a lot of edge cases when it comes to filesystem operations. It works for the simple stuff though (ex accidentally grabbing the wrong file or dropping it in the wrong folder). I mostly just use Ranger in a VTE to be honest. Cut/Copy/Paste and directional navigation of a tree using standard Vim keybindings is just more fluid than anything with a mouse could ever hope to achieve. Add to that dr…

Ranger is great; I do wish it had the ability to have windows rather than just tabs; it would be easy enough to setup an orthodox style view if that were the case.

Re: You Don't Need a GUI

#413

Earlier quoted context omitted.

its 5 keystrokes away on a gui ctrl+a shift+delete enter

Come on. Those are three separate actions of which the last one is to "confirm" the deletion in a modal dialoge. Hardly the same as one command in the CLI. Also if that would really happen, you can go into the trash folder and restore the items. AND of course that would only affect the current directory whereas `rm -rf ~` is a different story.

A nitpick, you cannot (easily) restore files deleted with Shift+Delete, but yeah I agree with the rest.

Re: You Don't Need a GUI

#414

Full disclosures: 1) I have an App - https://nocommandline.com - that is the opposite of this i.e. it says you should use a GUI instead of CLI (for a specific set of scenarios). 2) I'm not a 9-5 programmer even though I have a computing background At a very high level - I generally disagree with 'you don't need a GUI' or 'CLI is better than a GUI' At a nuanced level, I would say - it all depends. Sometimes CLI is muc…

> There is the argument that you can't automate GUIs

You generally can, and many times easier on Windows then any other OS. Accessibility OS features allow for that.

For example, Autohotkey is really great automation language for GUI and there is nothing like it on Linux world.

Re: You Don't Need a GUI

#415

Earlier quoted context omitted.

Can you explain more clearly what you mean? Why does the order of commands or their names have any influence on whether pipes can be used? How do you pipe the output of cp into awk?

> Can you explain more clearly what you mean? I can try ... Specifically, given a command that produces a list of "everything that can be done with the file", how do I cause the (unstructured) text of that list to be piped into a arbitrary other program, in the same way that `grep foo a.txt | bar` causes a list of occurences of 'foo' in a.txt to be piped into arbitrary program bar. > How do you pipe the output of cp…

Ah, thanks for the clarification, it definitely cleared up what you mean.

As I understood the suggestion re. file actions it is meant as some sort of interactive completion. So if I type the name of an image file and press tap, I am given the suggestions or options about resizing, format conversion etc. Several shells already have interactive completion of file names.

And I think that pattern makes sense from an exploration perspective. If you learn that file name + tab gives suggestions, then a lot of the learning about what the command line can do can be done directly in the command line.

And maybe it could be a command rather than a tab-press. Then it, given a file, prints typical actions/commands/tasks to stdout and then subsequent CLI tools can be used to process that output.

I really don’t see how this is incompatible with existing workflows :-)

Re: You Don't Need a GUI

#416

Earlier quoted context omitted.

For 90% of this stuff “discoverability” isn’t a problem anymore, I’ve already crossed the learning curve of the command line and I just think in terms of the available command line programs. For the next 5%, I tend to pipe a command like find or ls to a file and then use vim to quickly make a shell script that does what I need. I don’t know if it’s more efficient, objectively, but this just is the workflow that match…

I've been using the terminal (admittedly not as my main interface) for 20 years and I still have to consult man pages, documentation, and google about 10 times a day. I'd say discoverability is certainly still a large problem with CLI.

Apple had an interesting take on discoverability with AU/X and MPW: you could pull up a dialog box with the available options and descriptions. Unlike man pages, you could select the desired options from the dialog box and execute the resulting command. It's not the sort of thing you would want to use often, but it was great for learning how to do things or to refresh one's memory.

Re: You Don't Need a GUI

#417
post #363

Earlier quoted context omitted.

You did not get the point the parent (me) and grandparents made. They are not graphical programs. They are generally recognised as TUI programs. If these are graphical then so is Vi or the fancy powerline prompt. Our point was that you can also have command lines in graphical applications and WIMP in text mode applications. https://en.wikipedia.org/wiki/Text-based_user_interface https://en.wikipedia.org/wiki/WIMP_(co…

Of course vi is graphical. Vi is literally short for 'visual': it was created as a graphical extension of ex. The mark of a command line is a stream of commands and responses, not whether it does ascii art to emulate graphics.

I understand your point and your definition of GUI is much more inclusive. I however disagree with your definition and I consider it is not that commonly accepted.

I do agree with your definition of a command line interface as a stream of commands and responses.

Re: You Don't Need a GUI

#418
post #51

Earlier quoted context omitted.

Google has been around since 1998, and after 23 years, their search is still a CLI stuck in a form. > Me, on the other hand, I can point you to a trillion dollar business that uses only GUI and not a single CLI, to say the least. No you can't. There are 5 companies with a market cap over a trillion. We can easily rule out Apple, Microsoft, Amazon and Google as they have all developed CLIs. That leaves Saudi Aramco. D…

Yes, I can. Game industry. See my other response to one of your siblings.

The game industry uses CLIs in text adventure games, besides all their development tools. Many games put out utilities to enhance thier games, some of which have CLIs.

Re: You Don't Need a GUI

#419
post #340

Earlier quoted context omitted.

This comment was submitted entirely using the keyboard How did you do that? Using a specific browser extension? I am looking for ways to use my browser with keyboard only.

Worth noting there is no need for an extension. This comment is also submitted entirely using the keyboard. Tab navigates to the "reply" button.

This. Windows is almost entirely usable with the keyboard, including the file explorer.

Re: You Don't Need a GUI

#420
post #416

Earlier quoted context omitted.

I've been using the terminal (admittedly not as my main interface) for 20 years and I still have to consult man pages, documentation, and google about 10 times a day. I'd say discoverability is certainly still a large problem with CLI.

Apple had an interesting take on discoverability with AU/X and MPW: you could pull up a dialog box with the available options and descriptions. Unlike man pages, you could select the desired options from the dialog box and execute the resulting command. It's not the sort of thing you would want to use often, but it was great for learning how to do things or to refresh one's memory.

In zsh, I think Ctrl-/ pops up the manpage and then restores the command line when you quit (this may be just my config). It’s not as nice, but zsh’s line editor does implement everything you need to extend it with this sort of workflow
Post reply on HN