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

431–439 of 439 posts

Re: You Don't Need a GUI

#431

Post by imtringued »

bregma wrote: post #308
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... You know the secrets on how to use the Microsoft Windows 95 GUI so it's easy for you. Consider the person who has not been trained over years in its use. The concept of a context menu that pops up at the mouse position when clicking button number two is not intuitive or discoverable.…

The thing about graphical interfaces is that a lot of the lack of standardization is purely cosmetic. A context menu may have rounded corners, or a black background and so on but the user doesn't have worry about these differences.

Cosmetic differences in CLI applications are actually important to get them to work in the first place. dash vs double dash, equals sign or no equals sign. CLI parsing is completely nonstandardized. Each command reinvents parsing and is completely unpredictable.

The only way you could possibly solve this is by letting the shell parse CLI arguments and just pass them as a JSON like object to the application. The ship for that has sailed a long time ago.

Re: You Don't Need a GUI

#432

Post by Geezus_42 »

ronyeh wrote: post #401
least wrote: post #193

Earlier quoted context omitted.

While not entirely matching your vision for this, TLDR [1] does provide for a similar functionality (discoverability of functions of specific applications). This doesn't help when you want to map the fuzzy idea of performing a specific action to a particular existing program but it has helped me avoid having to search online for how to perform a particular task with ffmpeg. [1] https://tldr.sh

I was not aware of tldr. Thanks! However I think the tldrs need to be sorted better. When tldr git, the first example was Check the Git version: git --version Shouldn't the tldrs show me how to add, commit, push? Who knows. I think the tldr lists should be interactive and allow you to select by pressing 1-9. And maybe it should re-sort based on what you use most often, hehe.

You can edit them, there just text files.

Re: You Don't Need a GUI

#433

Post by Geezus_42 »

Geezus_42 wrote: post #393
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…

I feel like the autocomplete offered by fzf with * is a step in the right direction. I don't think it supports flags atm but that could probably be done with a script.

https://github.com/junegunn/fzf#fuzzy-completion-for-bash-an...

Re: You Don't Need a GUI

#434

Post by Can_Not »

alexvoda wrote: post #343
freeone3000 wrote: post #187

Earlier quoted context omitted.

Except modern UI design sort of threw the aspect of discoverability out the window. Context-sensitive elements, dependent elements, hidden elements, and the dreaded hamburger menu are all awful for discoverability, and they're present on nearly every GUI.

Correction, on nearly every GUI since 2009 (introduction of the iPad). Also, compared to the others you mentioned, hamburger menus are the most discoverable.

Yeah I'm confused about what OP meant was wrong with hamburger menu, the paradigm is "if the screen is too small for File | Edit | View | Etc. | Help, then collapse them behind the hamburger, which is generally good and sane.

Re: You Don't Need a GUI

#435

Post by hollerith »

bendiksolheim wrote: post #295
syl_sau wrote: post #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 d…

> 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. This might be the case for you, but please don’t mistake it for an objective truth. I find the terminal far superior for file manipulation than any of the graphical file explorers I…

Have you ever used Dired, the file explorer included in Emacs?

Re: You Don't Need a GUI

#436

Post by a1369209993 »

henrikeh wrote: post #427
henrikeh wrote: post #415

Earlier quoted context omitted.

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 expl…

Update. I tried the `file -u` example you gave above and the `-u` flag doesn't exist in my version of `file`. I also find it a bit hilarious that the example lists `ed` as the editor of choice.

> the `-u` flag doesn't exist in [any] version of `file`

Yeah, I was giving a example of a sensible way to design it, not documenting something that already exists; sorry if that wasn't clear.

> And maybe it could be a command [like `file -u FILE`] 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.

Pretty much that, yes.

> I also find it a bit hilarious that the example lists `ed` as the editor of choice.

I don't think unix had TECO as a standard utility, so I went with what was available.

Re: You Don't Need a GUI

#437

Post by filleduchaos »

boring_twenties wrote: post #428
syl_sau wrote: post #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 d…

Really. OK, rename all files ending in .foo to end in .bar instead. With the GUI.

Ironically, this is pretty easy to do in macOS' Finder.

Re: You Don't Need a GUI

#438

Post by tubularhells »

Nalta wrote: post #377
tubularhells wrote: post #293

Earlier quoted context omitted.

'Vim for everything' mentality requires a high degree of autistic behaviour in my opinion. I'm just not there on the spectrum.

hey, keep that shit on 4chan.

I'm autistic myself, diagnosed and all. I don't know what you are taking about.

Re: You Don't Need a GUI

#439

Post by JoBrad »

TeMPOraL wrote: post #366
jodrellblank wrote: post #364

Earlier quoted context omitted.

They have worked on improving error messages between Windows PowerShell and PowerShell, e.g. PS C:\> 1/0 Attempted to divide by zero. At line:1 char:1 + 1/0 + ~~~ + CategoryInfo : NotSpecified: (:) [], RuntimeException + FullyQualifiedErrorId : RuntimeException is now: PS C:\> 1/0 RuntimeException: Attempted to divide by zero. And everywhere else they've tried to make a shorter, clearer default error.

Good to know, thanks! I've been mostly developing on the Windows PowerShell, but I'm about to move to PowerShell/.NET Core, so I'm happy to know error messaging improves there.

Powershell Core is so much better. It’s updated much more frequently, and they address bugs so fast.
Post reply on HN