You Don't Need a GUI
261–270 of 439 posts
Re: You Don't Need a GUI
#262Earlier 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
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
#263There is no contradiction there really.
Re: You Don't Need a GUI
#264Re: You Don't Need a GUI
#265Re: You Don't Need a GUI
#266Earlier 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…
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
#267Re: You Don't Need a GUI
#268Earlier 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.
Re: You Don't Need a GUI
#269GUI 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…
Re: You Don't Need a GUI
#270Now 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!