Live data from Hacker News

You Don't Need a GUI

github.com

261–270 of 439 posts

Re: You Don't Need a GUI

#262

Earlier quoted context omitted.

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.

I think CLIs should be able to provide a very generic UI from their command definitions like this: https://github.com/hediet/ts-cli/blob/master/cli/README.md

Maybe one day everyone will adopt PowerShell as the CLI standard.

PS scripts (and even functions) declare command line arguments up front, and depending on how much time and thought you put into it, you can constrain the arguments quite well. See [0] for overview of the available functionality. A quick TL;DR:

- You can make parameters typed, and PS will handle relevant conversion if the user just types strings in. E.g. you can mark a parameter as [DateTime], and if the user types e.g. "2021-04-01", the script will receive an object that represents the midnight on that day. If the user types in "foobar" instead, they'll get an immediate error[1] telling them the parameter cannot be read as a date.

- Add [] to parameter type (e.g. [DateTime[]] instead of [DateTime]), and now the parameter can accept multiple values (arrays), - but behaves smartly if only one is given.

- You can mark parameters as mandatory. You can mark parameters as positional (i.e. provided without specifying parameter name on invocation). You can mark a parameter as designated "catch-all". You can define aliases for parameters, to allow user to write e.g. -Runs, -Run or -R, and have all three refer to the same parameter.

- You can mark parameters as "accepting values from pipeline" (and define how exactly). Since PS pipes transport typed objects, not raw bytes, this is how you can both set expectations, and write scripts that can flexibly mix pipes with commandline arguments.

- You can define validation for every parameter individually.

- You can group parameters into sets, based on what other parameters are provided, or some custom logic. So e.g. if arguments -A and -B only make sense together, and then -C doesn't do anything, you can encode this cleanly.

- Autocomplete in PowerShell is aware of all these things! It'll hint you appropriately. And you can provide your own autocomplete hints too.

How is all that relevant to this thread? The last point is a spoiler: all these declarations can be extracted from the script, and they provide enough information to build a high quality GUI for the script automatically. PowerShell ISE, that comes with Windows, exploits this to a limited degree - it contains a GUI for running PS cmdlets that lists parameters and their types, makes use of optional/mandatory status, and groups them by parameter sets. There's nothing stopping one from building an equivalent UI generator that would also provide custom widgets based on argument types (e.g. file pickers for paths, calendars for DateTimes, etc.).

--

[0] - https://docs.microsoft.com/en-us/powershell/module/microsoft...

[1] - Errors in PowerShell are a bit user-unfriendly. Niceties like invocation with underlined mistake are surrounded by long error text and small stack trace. I wish they improved on that; even for script developers, most of the error message is quite useless.

Re: You Don't Need a GUI

#263
I love using the terminal (fish shell, grep, find, mdfind, sed, etc etc). I also love using GUI applications such as Preview, Google Chrome, 1Password, Finder. And Emacs, not the least.

There is no contradiction there really.

Re: You Don't Need a GUI

#266
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…

when calling cheat.sh for youtube-dl, it appears to cite tldr:youtube-dl

So perhaps a suggestion could be to install tldr so as to be able to call a summary in your terminal without the need for web-access to cheat.sh

Re: You Don't Need a GUI

#267

Earlier quoted context omitted.

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

You said a business not an industry.

Exactly, I said business, not company. Gaming is a business, Apple is a company. Understand the difference?

Re: You Don't Need a GUI

#268
post #188

Earlier quoted context omitted.

Because it is obvious, but apparently not to the HN crowd. Let me name it then. Game industry, it's bigger than both music and film industry and it runs exclusively on GUI. Even text based games are GUI actually, not CLI.

You said "a trillion dollar business", not "a trillion dollar industry" so of course people misunderstood you! And even though the game industry primarily makes GUIs, it still uses CLIs everywhere in the development process, so it's pretty silly to say that it "uses only GUI and not a single CLI." And the console that's present in just about every game doesn't seem very "graphical" either.

That's their problem, not mine. Gaming is a business, Apple is a company. I heard plenty of times here on HN that Google's business is advertising. So go and argue this with the other million of post that uses this semantics.

Re: You Don't Need a GUI

#269

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…

Text-based interface with fuzzy contextual autocomplete is the best of both worlds. Think of an IDE's autocomplete popups, but for terminal commands. Or how the Command Palette in means I almost never have to memorise where some obscure setting because I can just type the first few letters and find it as a top match. No such UI exists for terminal emulators because they don't work that way, but I'm convinced if someone made a program entirely around text with autocomplete it would be just as accessible to non-technical people.

Re: You Don't Need a GUI

#270
I'm not sure if this is satire or not, but certainly the single worst case of using a terminal is file manipulation. Nothing will ever beat the right-clicks or Ctrl+C/Ctrl+V combos. It's just more natural to "see" things that you move.

Now when it comes to more complex applications, I'd stop using the CLI if I had to search the manpages or the internet each time for doing something I already did previously. Since I discovered the Ctrl+R shortcut (for searching your history), it has been much easier. You read the manpage once, maybe you do an internet search, you enter the command and then you can find it back as long as it's still in your bash history (be sure to set HISTSIZE and HISTFILESIZE to correct values). I also have a DOCS.txt file where I put all the rare but useful commands I'm afraid of losing. I don't need to be an expert in ffmpeg's options (... though I sort of am now), I can just look at my history or my DOCS.txt file!

Post reply on HN