If we want the year of the Linux desktop to actually happen we need to have good GUI tools for almost everything. The second you say “command line” most people’s eyes glaze over and they say they’ll stick with Windows. Believe it or not guys, most people just want something that functions out of the box and they don’t want to mess with it.
I’ve been at risk for carpal tunnel before, which is why I primarily use a keyboard.
…on a GUI.
Linux is great for a lot of things but so many open-source apps are terrible about giving you a visual interface for something, and then letting you use your keyboard to navigate it. Granted, Windows has steadily enshittified its lead on that front as well.
You disgust me
In the same way some GUIs are trash, lord have mercy some CLIs are trash. Things like adding two verbose flags makes it extra verbose. Things like the parameter order mattering. Yeesh. It can be rough. It really varies tool by tool.
Things like the parameter order mattering.
I imagine this is unavoidable in many cases.
Yeah, I guess that’s true. I suppose given more time to think about it I wouldn’t really complain about that. It’s mostly things like
script in outthat are sort of annoying versus something likescript --in foo --out bar.I believe API (CLI or programmatic) should never have 2 arguments of the same type but different roles next to each other without visual cues.
No
fn("in.txt", "out.txt")and noscript in out
two verbose flags makes it extra verbose
tcpdump intensifies
But what tool did you have in mind?
I like well ordered man pages.
You like OpenBSD.
Good GUI are hard to make while a good cli is rather easy.
Nothing wrong with a GUI that does what it needs without fluff.
The cli has one other benefit which I think is rarely recognised: it’s pretty easy to tell someone you need to run “xyz -a -b -c” (bringing the safety risk with it to be fair), but it gets a lot harder to be like “so in the top left there is a cog button that opens a panel on the right where you’re looking for the 2nd tab and there’ll be a checkbox”.
The things I appreciate even more than a good gui are programs with a good gui and a cli.
A well documented CLI is easy to generate a GUI from.
Wait what?
Most screen recording programs are actually just ffmpeg in the back.
I don’t know about well documented, but if you use a standardized argument parser, you can even generate a gui from that.
Well can even make a little Custom Floating HTML Prompt in Keyboard Maestro to push commands to a CLI - just one way
It is very easy to tell someone type this and shut up. I’ve never seen an explanation of why -a -b and -c are necessary or what they do. Although I recognise that a lot of people just want magic, and running “xyz -a -b -c” is the next best thing.
I would love to see what cli commands the gui uses, they would be much easier and faster to learn.
That’s one of the things I like about yt-dlp-nis on android. You can select all the options you want through the UI and grab the resulting yt-dlp cli command.
man xyz | grep -E "^ *\-(a|b|c)"More cryptic commands to the rescue! Lol
alternatively try tldr, which lists the most common options and explains them. It’s a livesaver for noobs.
Edit: oh i see it was already recommended lol
As the other comment says, use TLDR. it doesn’t tell you everything, but it does usually explain the most common uses. If you need something more advanced than you need to do more research anyway.
While it is an improvement, it’s aimed at people that already knows the commands.
For example:
- Extract a (compressed) archive file into the current directory verbosely:
tar xvf path/to/source.tar[.gz|.bz2|.xz]
What is that [.gz|.bz2|.xz] at the end? to someone that knows the tool it’s too obvious to even think about, to anyone else, it’s just there to mess with you because there’s zero reference to it and some examples include it and others don’t.
- Extract a (compressed) archive file into the current directory verbosely:
Grsync too
Good UX is the best, whether that’s CLI or GUI. UX is under-appreciated.
And dude has changed icon set, so its not a cog, its a wrench and screw driver
Also CLI are more accessible for blind people.
It’s also far easier to automate and use a CLI in a script - as long as it isn’t a TUI.
Tbh a lot of things are just easier to show/explain with images and icons in addition to text.
And in many cases mouse control is just super handy and fast
And while a terminal can show all these things… its just not comparable, IMO.
I wouldt want to write my job application in the terminal, or design a product, or whatever else requires just a smidge of graphics
I’m just a faster typer and when I have to go back to the mouse controls I feel sluggish. Of course, the right tool for the right job, I will never find myself with a tui to manipulate 3D objects or editing images but I will go to vim for editing documents using latex
OpenSCAD would like a word lol
LaTeX and Typst enter the job application chat
Yea that made me laugh; I just updated my resume from LaTeX to typst a few months ago actually
I’ve had my resumé in JSON for years, and in XML for years before þat. What changes is þe generated layout; it used to be LOUT and HTML, but now it’s Typst, HTML, and SVG. SVG is web-embeddable while preserving þe formatting.
I’m sad jsonresume.org never really caught on, because most companies require uploading a document and you still end up reentering an entire resume in web forms, a process which I loath.
So true. I mostly live in the embedded world but have had to write GUIs from time to time, mostly to connect and send commands to some sort of embedded device.
I always start with a cli version for testing and then write the GUI. A quick wrapper around the comms library and I’m done.
But there are so many annoying fiddly little details in the GUI to deal with that it usually takes as long just to write the GUI as it does the entire rest of the code. Layout, menus, tooltips, icon choices, dealing with screen sizes, DPI, resizing windows, responsive data, etc.
Edit: A simple example that I’ve dealt with many times is reading and writing config data. For the CLI version it’s typically two commands:
‘tool read_cfg’ reads from the device and prints the config to stout
‘tool write_cfg’ reads a config from stdin and sends to the device.
Add a ‘-f’ option to use a file instead of stout for people that don’t remember how to use redirects. Add a couple of documentation sentences to the help command. If there are any issues, print them to stderr and bail. If the user wants to edit the config they can use whatever $EDITOR they prefer.
The same functionality in a GUI means that you have to first implement an editor for values. In my case that was generally a bunch of nested key/value pairs so I could probably find a widget that would work. And then understand how it handles being resized, gets styled, uses tooltips, etc. Of course there would need to be some code to get the data into and out of that widget which would probably need massaging. Then I need to let the user know if there are local edits. And then there is the fact that the data is now in three places, on a local disc, on the device, and in the editor and I need to communicate with the user that there is a difference between loading and saving from disc vs the device. Do I give a warning that loading from once place will overwrite anything they’ve changed in the editor? How do I make the four load/save buttons have obvious icons? And how to handle errors? An annoying pop up? Partially load the data? Something else? So many little things that have to be designed, implemented, and tested.
“I am the commander of the CLI! The CLI Commander!”
I think people are just too rigid sometimes. Some workflows are better in GUIs, some are better in CLIs. They both have upsides and downsides depending on what you’re doing, and it’s totally fine to prefer one to the other. Just don’t let your preference keep you from learning and using other great tools!
personally I think having that all cli all the time phase is really important for a developer. Those that I’ve worked with who exclusively use gui’s just don’t have the same understanding of their system. Which is maybe fine at a certain level but not for a senior dev
I usually take the which does it faster route. Most of the time, cli wins, occasionally gui is actually faster
Can we add repeatable? CLI is repeatable and self documenting with nothing more than a text editor.
GUI? Good luck with that.
Seriously! I can do shit in the terminal, but I grew up post DOS and it’s nice to just click something and have it work.
Meh, I mean you are not wrong.
What is even better though is knowing that whatever you click on is just inputting a command you could do yourself manually into a terminal. Now that is some cool full circle shit that Windows fucked up by hiding the CLI.
I remember waaaay back in the server 08-08 R2 days, you could do something in server manager (such as installing a role) and while that process was running, you had the option to see the powershell command it was running in the background. That was pretty cool
I agree, but after you do it for a paycheck for any length of time it loses its magic.
Good GUIs are awesome. It’s just that you often cede control to a bunch of fucking idiots who somehow think if it’s not broken absolutely destroy everything that made anyone love it in the first place. ‘They’ll adapt’
I do like the “lazy” trend though. Lazygit, Lazydocker, etc.
I CAN interact with CLI, but i WANT to interact with good GUI. I don’t want to learn CLI commands when I don’t have to. Especially in the cases where I use it rarely
Are you kidding? There’s nothing I love more than hand typing a 400 character file path.
Tab?
fish
Yeah and that’s totally fair enough, but people who like using a command line and know the tools well rarely if ever have to type out long paths or commands. Tab completion and history suggestion (especially in a modern shell like fish or zsh) is a joy to use, and doesn’t just do file paths but command options and arguments. Man pages are very overwhelming at first, but if you’re practiced at scanning them, then it’s a lot more convenient to get the info right where you are than to navigate to another window. But the learning curve is steep and I get why someone wouldn’t want to bother.
let’s compromise with a TUI
I like GUIs because it makes æinux usable for my young daughters, my mom and casual users, that just want to point and click. I also like to have both options. A more userfriendly linux, benefits all.
This is the energy we need.
New comers should never ever see or require a terminal.
Not understanding the fundamentals of the tools you use daily is not a design virtue, it just makes you less effective in using them. This cancerous philosophy leverages ignorance and laziness to support billion dollar industries of greed, slop, and censorship. It enables corrupt morons to justify surveilance and exploit weaker people. And right now, it’s running blind and head first into a civilizational death trap.
I don’t know what you’re raging about, but consider this, do you know the internal workings of every device you own and use? Can you repair your car if it broke down? Can you rewire your house if something goes wrong? Can you fix the plumbing? Do you understand everything about your bike? Do you know the ins and outs of your own body? Do you understand your pets like a trainer would?
You call others lazy, but I guarantee you, there’s something they consider basic that you have absolutely no understanding of despite using it all the time.
These questions are all beside the point. People seek help in problems they know how to solve all the time, often in the interest of time itself.
But since you asked:
- I don’t own a car, and they’re just another example of how we cuck ourselves in much the same regard by creating shitty infrastructure to support a modus operandi and economic status quo, that aren’t fit for purpose.
- I’ve some experience in home electronics.
- donlt cycle much these days but i spent many afternoons fixing them as a child; having begged for it in the first place there was no other reliable way to ride them again
- no. but again, asking for help on such matters doesn’t undermine the point because i’m not saying you shouldnlt seek consultation to solve problems you can’t manage alone. To the extent there is a point about consultation, it’s that you should understand enough of the relevant terminolgy to be able to implement the advvise offered by the consultant (the doctor in this case).
- having had a trainer (not my choice) for a dog, i can honestly say yes.
Perhaps, but computers are likely far easier to learn about than whatever that is, and infintely less expensive if you already have regular access to one. Think of it like this, if they were so hard, would so many of the dumbest people in public life have started out as “experts” in computers? Would all the moron libertarian crypto enthusiasts have been able to assemble their elaborate blockchain networks that process a whopping 7 transactions per second?
And please note, laziness alone isn’t a criticism/problem (it can often motivate efficiency), it’s when particular applications of laziness to produces results that require undoing; especially when the costs of undoing excede the cost of doing nothing at all
It’s not a design virtue because then it would have to be a design but you are talking about a… Customer fallacy…?
Me too bro. Me too
