Live data from Hacker News

You Don't Need a GUI

github.com

301–310 of 439 posts

Re: You Don't Need a GUI

#301

> $ cp readme.txt documents/ sure, works fine in my ~, I have the follwing files: 'FOPC_0211237F_4563(1).pdf' FOPC_0211237F_4563.pdf FOPC_0251215K_4563.pdf FOPC_0381912X_4143.pdf FOPC_0381912X_4154.pdf FOPC_0755890V_282.pdf FOPC_0755890V_283.pdf FOPC_0755890V_284.pdf FOPC_0755890V_285.pdf FOPC_0755890V_286.pdf FOPC_0921204J_4652.pdf FOPC_0952259P_58.pdf FOPC_9830445S_4142.pdf Even with the very good zsh autocompletio…

either those file names mean something and you don't have to look at the thumbnail or you should use a better naming convention...

I wholeheartedly agree about the edgy teenager who just discovered bash

Re: You Don't Need a GUI

#302
post #33

Earlier quoted context omitted.

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?

The "find . -print | sed -e 's;[^/]*/;|____;g;s;____|; |;g'" is a bad joke. Heck, it's better to just tell them to `brew install mc` and use `mc` afterwards (or `exa` or whatever else). I usually just type `open .` and do the rest in Finder, although this admittedly breaks the command line workflow. No matter how fast you can type, typing this clusterf*ck of a command isn't faster than using a better utility (command…

it's there, `brew install tree`, he should have simply left it at that, but the urge to brag prevailed

Re: You Don't Need a GUI

#303

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 get what you're saying but I think it depends on what sort of file manipulation you need. When I'm trying to get a large set of images renamed from e.g. IMG_NNNNNN.jpg format into sequential zero-padded numerals for use with ffmpeg I personally appreciate the option to do it with a bash one-liner rather than using the mouse in a GUI.

Re: You Don't Need a GUI

#304
post #296

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…

> It's just more natural to "see" things that you move. This is the fallacy of logos. When I was learning about files and filesystems, the GUI had not even been invented. It is certainly not natural to me to conceive of file operations as cartoons moving around on a TV screen. What's happening here is you're mistaking what you may have first learned for what is normal or natural. That it seems normal or natural to yo…

I get their point, though. It's less about seeing the animation of the move, and more about seeing state. Seeing state you're manipulating is helpful. CLIs, being naturally line-oriented, don't give you that.

Myself, I do a lot of file management in Emacs these days. Dired - Emacs folder viewer - essentially turns output of `ls` into interactive folder listing, that you can manipulate the way you'd use an orthodox file manager like Norton Commander or Midnight Commander, but that you can also just edit as text and have Emacs apply changes to the file system. To kind of boost your point about "normal" being learnable, it's absolutely normal for me now to expect to be able to rename files or change permissions by editing output of `ls`.

Re: You Don't Need a GUI

#305
post #299

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…

For some strange reason I have a GUI (nautilus), TUI (mc) and CLI (fish) at my disposal... but I do lots of file manipulation at CLI. Nothing will ever beat `massren` with the power of `vim`. (But no kidding: somethings feels CLI very natural, sometimes feels GUI more natural for me.)

FWIW, `massren` + vim (or dired in Emacs) is TUI, not CLI. GP's point absolutely applies to pure CLI - operating on files by directly invoking mv, cp, ln, etc.

Re: You Don't Need a GUI

#306

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…

Do TUIs count as GUIs? Midnight Commander ( mc ) is a TUI file manager with mouse support. edit I see others beat me to it in mentioning mc. I'll leave this here anyway.

It depends on the context. For the purpose of this subthread, TUIs belong with GUIs, as both show you current state, make it interactive, and render a 2D view. In contrast, CLI tools only print out a snapshot of the current state (i.e. the output becomes stale as soon as it hits the TTY), and that snapshot is non-interactive.

In other contexts, you'd group CLIs and TUIs together. For example, both can be used from a terminal emulator, both are easy to use over SSH connection, and (an underappreciated feature) in both CLI and TUI apps, it's easy to just copy what they show as text.

Re: You Don't Need a GUI

#308

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.

My wife, for example, grew up before Windows 95 and its descendents were invented, holds multiple post-secondary degrees, and works with computers every day. She has no idea a second mouse button exists let alone that she can use it to perform file manipulation operations. She doesn't quite get the idea of "home directories" or "nested folders" or anything that is hidden like menus (or, frankly, tabs in the browser.. or multiple browser windows in fullscreen mode). Those things are not intuitive or discoverable in any way if you haven't been trained in their use. I, too, often forget the context menu is there although with practive I'm getting better. I certainly would never forget the `df` command though because it's second nature to me after over 40 years of use.

People need to be very careful when making an argument that something is better because it's what they're familiar with as if they are some definitive exemplar.

Re: You Don't Need a GUI

#310
post #243

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.

For everything negative you can say about modern UI patterns like the hamburger menu, lack of discoverability isn‘t one of them imho. You have a single button with an almost-standardized icon, from which you can get an overview of all the (non-context-sensitive) actions. Relative to menu bars, the actions are sorted more by their importance than some vague categories. (Where do you find Settings? Under File, Edit or…

Hamburger menus work because software that employs them is trivial. Often not far from a toy MVP. Discoverability is easy when there's not much to discover.

All the pre-Web UI patterns start to shine when you're working with more powerful software tools - where there are more than half-dozen available actions, so you can't just stuff them under a single hamburger list. You have to start categorizing, grouping actions by their commonalities. You can't sort by importance, because importance changes from minute to minute.

And menus of old were plenty discoverable. They weren't categorized for discoverability, because that's not the job of categorization. If you want to discover what the software can do, you spend 60 seconds expanding every single menu and reading available options. The categorization is there to introduce grouping concepts that are easy to remember, so that next time you're looking for an action you know (or suspect) exists, you know where to look for it.

Post reply on HN