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

281–290 of 439 posts

Re: You Don't Need a GUI

#281

Post by megous »

dekerta wrote: post #33
gruez wrote: post #5

Most the things in this list are things that you technically don't need a GUI for, but a GUI is so much better that doing it in command line is pointless. For instance, you could do all those file operations in the terminal, but chances are you're already browsing files using a GUI file manager so opening a terminal to do those things is pointless. Terminal is great if you want to do something complicated that a GUI…

No kidding. I laughed at this part: "STOP DOUBLE CLICKING ON A FILE " "Instead type '$ xdg-open file'" Yeah, because that's way faster and more convenient than double clicking on an icon. This one is great too: Don't open the file explorer! Instead you should type "find . -print | sed -e 's;[^/]*/;|____;g;s;____|; |;g'" Seriously?

It often times is faster, or roughly the same speed. What's your point?

Say I want to edit .psqlrc

Doing it in GUI is like 10x slower. First dot files are usually hidden by GUI, so I have to search through menus on how to enable their display. Then I have to look for the damn file. Where it is among 200 similar dotfiles? 5s later I find it. Now right click, pick an corect editor from a submenu of a context menu. Edit. Save. Now go back to file browser and disable dotfiles display, otherwise all my regular files get drowned in noise, slowing the normal usage. It's retarded.

Alternative. Open terminal. Type vim .psqlrc. Edit save. Close terminal. 3s top for the non-editing parts of the workflow.

Re: You Don't Need a GUI

#282

Post by skissane »

rewgs wrote: post #130
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 totally agree, and this is one reason why, broadly speaking, command line applications often turn me off, even though in theory I prefer them for the reasons you laid out. There's a sort of implication that you're not "in the club" if you don't remember this or that flag. Why then isn't a kind of very simple approximation of a GUI (or, at least, easily-discoverable commands) more common in command line applications…

> Why then isn't a kind of very simple approximation of a GUI (or, at least, easily-discoverable commands) more common in command line applications?

On IBM i (originally known as OS/400), you can press a function key and automatically get a fill-in-form for any command.

This is because command line syntax is defined, not in your program's code (getopt calls etc), but using declarations in what you might consider to be a separate command definition file (technically called a "*CMD object"). The OS does command line parsing and validation, marshals the result into a memory block, and passes that to your program rather than the raw command line. And the OS uses the same command syntax declarations to generate the (text mode) fill-in form for display.

Other systems which use the idea of command line syntax declarations, with the shell doing option parsing based on those declarations instead of each program doing them itself, include OpenVMS DCL and PowerShell. (PowerShell actually copied this idea from OpenVMS DCL and IBM OS/400.)

I think the big reason why this is less common in Unix-like systems, is the design decision to give each command responsibility for parsing arguments/options, rather than doing it in the shell. This makes the whole approach of automatically generating fill-in forms at the worst impossible, at the best unreliable. You can try parsing --help output or man pages, but that method isn't always going to work, centralising option parsing in the shell does. It is likely rather too late for Unix-like systems to change their approach.

Re: You Don't Need a GUI

#283

Post by enriquto »

GUIs are very useful for non-verbal animals, and for young children and heavily handicapped humans who cannot use language. For normal, well-functioning adults with a command of language, text or voice-based interfaces will always be superior: they are both faster and more expressive.

Re: You Don't Need a GUI

#285

Post by phtrivier »

I have a problem with the very first entry:

``` cp readme.md documents/ ```

It misses the point of: "How did I get to the place where the "readme.md" file is ? How did I know I wanted to put it in `documents/` ?

I'd argue that this is not what most users are really doing is.

A real-life scenario is:

1. I need to send a file to Bob. Where the hell is that file ? I think it's in the "Files" directory. No wait, is it in "Documents". Oh, ok, it's in "Project X254/Documents/Files/Revision0/VersionB". 2. Right-Click on Icon, Click Copy. 3. Where the hell do I need to put it, again ? Ah, ok, I need to put it in "Windows Share/Shared/Team/Multiple/Document/Files/Next Very Important Meeting" 4. Right-Click on Icon, Click Paste.

Using a CLI does not make steps 1 or 3 easier ; it makes step 2 and 4 unbearable (because you have to type _names_ right, and _names_ written by human beings are hard.)

Re: You Don't Need a GUI

#286

Post by nicoburns »

skissane wrote: post #278
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 than you move. I've been using a Mac full-time for the last 8 years, and I do the vast majority of file manipulation in Terminal instead of Finder, because I find the command line easier and more i…

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.

Re: You Don't Need a GUI

#287

Post by thomasahle »

phtrivier wrote: post #285

I have a problem with the very first entry: ``` cp readme.md documents/ ``` It misses the point of: "How did I get to the place where the "readme.md" file is ? How did I know I wanted to put it in `documents/` ? I'd argue that this is not what most users are really doing is. A real-life scenario is: 1. I need to send a file to Bob. Where the hell is that file ? I think it's in the "Files" directory. No wait, is it in…

You don't have to type the names, you only need the first character + tab. To me that's much faster than reading through a list of folders trying to find and click the right one.

In case one of those folders only contain one other folder, you don't even have to type the first character, just tab+tab+tab done.

Re: You Don't Need a GUI

#288

Post by alexvoda »

jcrawfordor wrote: post #146
rewgs wrote: post #130

Earlier quoted context omitted.

I totally agree, and this is one reason why, broadly speaking, command line applications often turn me off, even though in theory I prefer them for the reasons you laid out. There's a sort of implication that you're not "in the club" if you don't remember this or that flag. Why then isn't a kind of very simple approximation of a GUI (or, at least, easily-discoverable commands) more common in command line applications…

The practice you recommend was basically codified as IBM Common User Access, now recognized by some as the UX convention of IBM mainframe software --- one component of CUA was a list of available actions and their assigned function keys, at the bottom of the screen. CUA itself was not widely used, but was highly influential in IBM's greater orbit of software vendors, including Microsoft. As a result, many, but not al…

You touch upon the problem. The space is actually bidimensional instead of unidimensional.

On one axis we have graphical (raster mode) at one end and text at the other. On the other we have as you calld them action-oriented (WIMP) and line-oriented (I would call it command-oriented).

There are text mode action-oriented apps: ncurses/turbo vision/etc. based applications like *Commander, or the old Borland IDE, or Tilde, or the old FoxPro, or plenty others.

And there are graphical command-oriented apps like Jupyter or ReGIS or Sixel or iTerm or TermKit or Kui or the command palette in VSCode or Atom or others.

And you can have them mixed like in youtube-dl GUI or ffmpeg GUI where the changes you make in the GUI are reflected in different arguments for the command and you can see and edit the command before executing it. This is similar to getting keyboard shortcut suggestions in menus or tooltips.

We need more innovation in this space. Ways to achieve both discoverability and scriptability. We need more hybrids and less systems that stay in their lane. Graphical text editors with command pallettes, PowerShell with its object oriented piping, Jupyter are moves in this direction.

This is a power user direction. And it is opposed both to the minimalist touch friendly trend and to the terminal-first mindset.

Re: You Don't Need a GUI

#289

Post by thomasahle »

dekerta wrote: post #33
gruez wrote: post #5

Most the things in this list are things that you technically don't need a GUI for, but a GUI is so much better that doing it in command line is pointless. For instance, you could do all those file operations in the terminal, but chances are you're already browsing files using a GUI file manager so opening a terminal to do those things is pointless. Terminal is great if you want to do something complicated that a GUI…

No kidding. I laughed at this part: "STOP DOUBLE CLICKING ON A FILE " "Instead type '$ xdg-open file'" Yeah, because that's way faster and more convenient than double clicking on an icon. This one is great too: Don't open the file explorer! Instead you should type "find . -print | sed -e 's;[^/]*/;|____;g;s;____|; |;g'" Seriously?

> Instead you should type "find . -print | sed -e 's;[^/]*/;|____;g;s;____|; |;g'"

They do say you can just write `tree` on Linux. If you don't have that command, you can just alias `tree` to the find command.

Re: You Don't Need a GUI

#290

Post by [deleted] »

dekerta wrote: post #33
gruez wrote: post #5

Most the things in this list are things that you technically don't need a GUI for, but a GUI is so much better that doing it in command line is pointless. For instance, you could do all those file operations in the terminal, but chances are you're already browsing files using a GUI file manager so opening a terminal to do those things is pointless. Terminal is great if you want to do something complicated that a GUI…

No kidding. I laughed at this part: "STOP DOUBLE CLICKING ON A FILE " "Instead type '$ xdg-open file'" Yeah, because that's way faster and more convenient than double clicking on an icon. This one is great too: Don't open the file explorer! Instead you should type "find . -print | sed -e 's;[^/]*/;|____;g;s;____|; |;g'" Seriously?

[deleted]
Post reply on HN