Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

You Don't Need a GUI

github.com

Post reply on HN
Print view View original

251–260 of 439 posts

Re: You Don't Need a GUI

#251

Post by iggldiggl »

_Microft wrote: post #228
sbuttgereit wrote: post #24

Earlier quoted context omitted.

A fair part of what I do includes ERP implementation project work. Way back, when TUI/keyboard centric ERP system dominance was starting to give way to GUI/mouse centric ERP systems, I was working with one client where replacing a TUI with GUI based system. One measure we made during the project was the impact to new employee training time and we saw significant reductions in training time due to the sorts of discove…

What about a system that shows actions in a GUI as a list of equivalent plain text commands. New users would have the discoverability of a GUI while being able to see what goes on command-wise. With time they would be able to convert to plain-text commands and scripting for increased efficency.

AutoCAD sort of does that - actions can be launched both via the GUI and the command line, and all actions launched via the GUI also appear in the command line history, so you can pick up the names of the commands over time as you're using them (alternatively, they're also mentioned in the mouseover tooltip in the GUI).

Re: You Don't Need a GUI

#252

Post by berkes »

ronyeh wrote: post #179
berkes wrote: post #176

Earlier quoted context omitted.

Would tab completion be a startingpoint for this?

Yes, I love tab completion. When I enabled tab completion for git and google cloud CLI, my life became much better. However, I still think there needs to be a "right click menu" for command line programs. Someone needs to determine the 3 most common uses and make it so that --help lets me choose one of them by pressing 1, 2, or 3. Right now, --help usually gives me something that is difficult for me to understand, es…

hence the "starting point".

Tab-completion could additionally list the "most common things given the context* I have".

Tab-completion needs not nessecarily be postfix. I've seen completion tooling** that would work somewhat like `invoice.pdf -> `open invoice.pdf\n cp invoice.pdf` etc.

And if `` conflicts, or breaks your mind because it must only work on postfix, it could be anything really, such as `-r`.

Additionally, or underlying, a reasonable simple command like `whatcan` or `ctxt` (context) could work and be leveraged: `whatcan invoice.pdf` -> a list of common commands given the context* I have.

---

* Context I have would be your ~.\_history, the current directory-tree, permissions (why show `mv` if you don't have write access?), applications available, etc. pluggable maybe?

** e.g. the -r, interactive bash history search come to mind as pattern. But also tools like FZF https://github.com/junegunn/fzf#fuzzy-completion-for-bash-an... that don't nessecarily only "complete" on tab, but may replace larger parts of the commandline.*

Edit: formatting.

Re: You Don't Need a GUI

#253

Post by slightwinder »

karlicoss wrote: post #11

GUI is better for discoverability of the most common scenarios (I can right-click to see everything that can be done with the file, including some third party programs). But it's bad for composing programs and interoperability, often it's impossible or very hard to automate (how many people are doing UI testing? there is a good reason it's not many -- it completely sucks) TUI/console is very good for interoperability…

> GUI is better for discoverability of the most common scenarios (I can right-click to see everything that can be done with the file, including some third party programs). But it's bad for composing programs and interoperability, often it's impossible or very hard to automate

I think that's more a design-problem than actual trait of GUIs. GUIs have evolved that way, but there is no reason why they can't support composing and interoperability too. MacOS, KDE and Web-UI showed how it's possible to do. It's just that nobody ever went to the full way to build a GUI-Framework from ground up that is reaching the same level of automation as shells.

> TUI/console is very good for interoperability/automation/muscle memory,

TUI and console is not the same. TUI is a GUI inside the terminal, thus usually only with text. Vim, emacs, mc or any curses-app is an example of TUI. And how well can you automate and support interoperability with them really? As I know, all the automation and interoperability comes from the devs adding it on purpose, it's not there by design, or as easy as with a shellscript.

> If I don't remember the `df` command... what do I do apart from searching on the internet? Maybe searching man pages, but it isn't as fuzzy (e.g. `man -K "free space"` isn't very fruitful). In comparison, I know that if I start going through GUI, eventually I'll eventually find the free disk space info.

To be fair, GUIs can also have complex workflows and undiscoverable features. It's just common sense that GUIs have menus for every possible action. A GUI is a canvas, and there are established languages which creates frameworks of content which you should paint on this canvas. But this doesn't mean you speak one of this languages well or even at all.

Re: You Don't Need a GUI

#254

Post by [deleted] »

silveri wrote: post #205
ronyeh wrote: post #174

Earlier quoted context omitted.

I like your point about discoverability. What if there was such a thing as a right click menu for command line programs? Like if I type ffmpeg or youtube-dl with no args, it lists the 3 most common ways to use it, and maybe allows an interactive CLI menu where you can build up the correct argument list by answering a few questions. I would love the most useful commands to look like: ffmpeg --resizeVideoTo input.mp4 5…

That's basically what cheat.sh does. It's an editable wiki that contains common use cases (cheat sheets) and can be called directly from the command-line, e.g.: curl cheat.sh/ffmpeg curl cheat.sh/youtube-dl curl cheat.sh/cd curl cheat.sh/find It gives quite a bit more than 3 use cases, but you could do: curl -s cheat.sh/ffmpeg | head For more details you can go to the site in a browser or use: curl cheat.sh curl chea…

[deleted]

Re: You Don't Need a GUI

#255

Post by inetknght »

adwn wrote: post #219
inetknght wrote: post #163

Earlier quoted context omitted.

> GUI is better for discoverability of the most common scenarios (I can right-click to see everything that can be done with the file, including some third party programs). No. One has to be trained to right-click. What about interfaces that don't have a right-click, such as a touch interface? Not only that, but the right-click menu has to be programmed. A lot of designers want minimalistic interfaces and would remove…

> What about interfaces that don't have a right-click, such as a touch interface? Are you suggesting that we switch to TUIs/CLIs on touch interfaces? If not, what's your solution? > I've found that doing one-off things is massively easier and faster in a TUI than in a GUI! For example?

> Are you suggesting that we switch to TUIs/CLIs on touch interfaces? If not, what's your solution?

My solution is that touch interfaces are a bad design in the first place. They're significantly less accessible to people with disabilities. They present a lot more problems with feedback about which buttons you're _about_ to press. And they're ficking obnoxious because everyone and their marketing team wants a completely different interface so nothing is ever consistent even on the "same" operating system.

> For example?

Example 1: download one file from a url mentioned somewhere

    curl -fLsS "$(query for url)" -o ~/Downloads/file
Example 2: download a bunch of PDF files

    cat ./file | grep -P '\.pdf$' | while read -r url; do curl -fLsS "${url}" -o ~/Downloads/"$(basename "${url}")"; done
Example 2: move all PDFs that I just downloaded:

    mv ~/Downloads/*.pdf /path/to/pdfs
Example 3: find what text file(s) have some text

    grep -nRIiw "magic" /path/with/content
Example 4: find what pdf file(s) have some text

    find /path/to/pdfs -iname '*.pdf' -exec pdfgrep "magic" {} +
Example 5: compare filenames in the two sets:

    sort
And now, I have accepted a file from a team member which describes URLs to PDF reports with magic. I have generated a one-off report describing which files have magic content that needs to be reviewed because it contains magic that's described in in a local database.

How about generating a git-diff, encrypting it, and emailing it?

    cat
... Okay so those one-off things are complex things. How about simple things?

Example 6: move a file.

     mv ~/Downloads/foo ~/Documents/
Example 7: open a file

    xdg-open file
Example 8: delete a file

    rm file
Example 9: mount a thumb drive

    mount /dev/device /mnt/filesystem
Example 10: unmount a thumb drive

    umount /mnt/filesystem
Example 11: shutdown, and don't let any bad app stop the shutdown

    systemctl poweroff --force
All of these are IMO easier than in a GUI

Re: You Don't Need a GUI

#257

Post by Blikkentrekker »

g.u.i. is a buzzword I know not of what it means and it seems fairly useless and bereft of any actual technical definition. I know what a c.l.i. is and what it is not, and I also know that the two are not exclusives, and where the border of what is and isn't a g.u.i. lies is very vague.

I'm fairly certain that the console I summoned in Counter Strike when I was younger qualified as both a command line interface and a graphical user interface.

When discussions use such ill-defined terms, I smell the stench of social tribalism more than anything.

Re: You Don't Need a GUI

#258

Post by adwn »

inetknght wrote: post #255
adwn wrote: post #219

Earlier quoted context omitted.

> What about interfaces that don't have a right-click, such as a touch interface? Are you suggesting that we switch to TUIs/CLIs on touch interfaces? If not, what's your solution? > I've found that doing one-off things is massively easier and faster in a TUI than in a GUI! For example?

> Are you suggesting that we switch to TUIs/CLIs on touch interfaces? If not, what's your solution? My solution is that touch interfaces are a bad design in the first place. They're significantly less accessible to people with disabilities. They present a lot more problems with feedback about which buttons you're _about_ to press. And they're ficking obnoxious because everyone and their marketing team wants a complet…

> My solution is that touch interfaces are a bad design in the first place.

Don't get me wrong, I also hate touch interfaces, for all the reasons you mentioned. But saying they're "bad design" is not a solution – it's a starting point at best.

What alternative are you suggesting for smartphone-sized devices? Mobile phones did have physical buttons, but once touchscreen-only devices came out, customers voted with their money. So much so, in fact, that smartphones with a physical keyboard are a tiny niche today. That's because keyboards just don't work well with small devices. Using a CLI with a smartphone keyboard would be an awful experience.

Re: You Don't Need a GUI

#259

Post by mattmanser »

BeetleB wrote: post #103

As much as I like the command line, I couldn't help noticing from the first 10 or so entries[1] that the "stop" text consists of one of: 1. Drag and Drop 2. Right clicking 3. Ctrl-C and Ctrl-V So these 3-5 things do everything in the list in a GUI, and instead the author wants us to learn 35 different command/syntax combinations? As an aside, I'd like to write an article saying "You Don't Need Github To Write an Arti…

I thought the page was a joke, showing how bad CLIs are.

You think he's being serious?

Re: You Don't Need a GUI

#260

Post by Dariof4 »

ponytech wrote: post #214
userbinator wrote: post #63

Earlier quoted context omitted.

Yeah, because that's way faster and more convenient than double clicking on an icon. It is if you happen to have both hands on the keyboard. That said, I usually navigate a GUI file explorer using the keyboard too, so pressing Enter to open a file is even faster. (This comment was submitted entirely using the keyboard.)

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.

I use Qutebrowser which works well and is configurable, though there's no extensions which can be a bit of a bummer, but there's a built in adblocker which works pretty well at least.
Post reply on HN