A gui is helpful sometimes, but thereβs a lot of cases where thereβs no feasible way to make a good gui that does what the terminal can do.
Right tools for the right job.
For example, a gui to move a file from one folder to another is nice - drag and drop.
A gui that finds all files in a directory with a max depth of 2 but excludes logs and runs grep and on matching files extracts the second field of every line in the file? Please just let me write a one liner in bash
Me fucking with hard drives/partitions : GUI please
Me doing pretty much anything else - Terminal
I see a lot of people saying they have to use a GUI tool for partition management, and Iβve never understood why.
Text based tools like parted are fairly easy to use, at least compared to other terminal tools the same people are able to use for other tasks.
What is it about partitioning that needs a GUI when other tasks donβt? Is it the visual representation of the partition layout? A general fear of borking a disk?
Surely youβve used something roughly equivalent like searching a text, be it web page or other document, for a word or filtering a spreadsheet?
How would one use grep for a webpage in a browser? Does the page need to be accessed outside the browser?
Disagree. Anything that can be done with terminal can be done with a GUI, you just need to be good at UX. Most programmers I know are pretty bad at UX, and program for themselves, not the user.
Edit, just to clarify (because I know some of you will feel personally attacked): Iβm not saying a GUI may be better, or more efficient than a CLI, Iβm just saying that it can be done. And as an example, see 3D shaders in modern programs, that need no code at all and are purely visual. That was unthinkable some years ago.
Thatβs just not true. Not without lots of hand waving.
In my terminal I can, and pretty much hourly do, combine many programs in chains of input and output to perform specific tasks and get information I need. And thatβs how these programs are designed to be used. The programmer builds it to do specific things and then the user can combine the program with others in novel and nearly endless ways.
With a GUI, sometimes thatβs possible between two programs if you can copy/paste between them but itβs much less reusable and a lot more tedious. But usually itβs just not possible because theyβre designed for specific user personas and not as general purpose tools that may be part of a script.
Well, seeing the progression of 3D programs and how a lot of complex operations are nowadays done in a visual way, I guess we wonβt agree on this one, I guess.
But I affirm in my conviction that anything can be made with a GUI. It may be difficult to reach a suitable GUI, with a lot of back and forth, and probably a lot of user feedback, but with a good methodology and a good understanding of UX, it can be done.
Sad we canβt agree. Cheers.
They tried to replace programming languages with drag-and-drop toolkits too. It can be done, but sometimes thereβs a reason we donβt do it.
But Iβm not talking about programming languages, Iβm talking about CLI programs, or system commands.
And Iβm not telling a GUI would be better, or more efficient, Iβm just saying that it can be done (something you are saying too about programming languages).
Thatβs the point: a GUI can replace a CLI. Is it better? Sometimes it is, sometimes it isnβt. Is it possible? Absolutely.
How would you implement piping in GUI?
Could you show us an example program with a GUI you created for this?
To play the opposite team a bit here, I like the idea Android uses of Intents for something like this. I think it falls apart a bit in reality because app companies kinda want you in their garden and so donβt often do the work to keep things interoperable. That and the use cases from users on phones donβt frequently involve cross app functionality. But the ability is powerful for apps to say βmy app needs a user photoβ or one of my faves βmy app needs a pgp provider (for the password store app)β and then let the other app do that piece of functionality as determined by the OS, which tracks a lot of those providers and lets the user decide which to use.
https://en.wikipedia.org/wiki/Automator_(macOS), or in general, https://en.wikipedia.org/wiki/Visual_programming_language
'Course, thereβs a reason those things basically never catch on, which is that they donβt actually reduce the inherent difficulty of figuring out the algorithm, and for anything non-trivial messing with a whole bunch of drop-down lists and shit is more cumbersome than just typing the damn thing.
Are you talking about sending the output of one process to the input of another?
I think the shaders Iβve mentioned are a great example of that: you do something in a block, then send the result to the input of another block.
Sorry if itβs not what you mean, but my point is that, with some effort, you can create a visual representation of even the most abstract concepts. Physicists do this constantly. If we can make a visual representations of 4D, for example, what prevents us from doing the same for programming logic? Or for commands?
Most programmers are bad at UX but not nearly as bad as GUI designers are at understanding abstraction.
Thatβs your opinion, and I disagree with it. It takes a lot of abstract thinking to synthesize an action in a visual way, like an icon.
Designers are good at lateral thinking, and founding visual ways of representing abstract concepts (and you canβt represent something visually if you donβt understand it first).
You can have your GUI do anything a terminal can I guess, but youβd need a few million buttons on that gui where the programmer has anticipated each and every combination of CLI command that you are going to use, encoded that to a button or menu, included text entry boxes for each variable and have bundled every program, application and dependency that has ever existed. Totally possible.
Super + T in my case, but stillβ¦
(shhh π€«, itβs actually the win key, but donβt let the Linux users hear ya π€«)
For me, itβs:
mod + returnfor terminalmod + efor file managermod + rfor dmenu/bemenumod + dto switch to the next empty workspace.
All because I have to work with win10 workstations and using a different, superior shortcut scheme would mess up my muscle memory. Remembering to use shutdown -s -f -t 0 instead of poweroff is difficult enough, and donβt even get me started with the audacity to use curl as an alias for Invoke-WebRequest!
I have to confess. I had to look up the shortcut for terminal because I havenβt interacted with a Linux desktop in years. Iβm a Windows cuck, but not a total imposter bc Iβve kept a debian server running on my network for years. Whenever something breaks or I do an update (the updates are invariably the cause of the breakage) I manage her with ssh.
I use Super+Return
Honestly, I like both. I use whichever provides the biggest productivity multiplier. For example, I can navigate around the filesystem and manipulate text files and code extremely quickly in the terminal. On the flip side, I like to use a gui which allows me to spread 6-12 terminal windows across my multiple displays.
The terminal is not fancy, or pretty, and its not that nice to use, but its always available and it gets the job done, just like OPs mum
My terminal is pretty, fancy, a nice to use. Iβm not sure, you might be using the default LXDE terminal or something like that, but some people take the time to make their terminal enjoyable.
I like to use starship.rs
