1377
Ctrl+Alt+T
(lemmy.world)
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 10 Dec 2023
1377 points (100.0% liked)
linuxmemes
21234 readers
21 users here now
Hint: :q!
Sister communities:
- LemmyMemes: Memes
- LemmyShitpost: Anything and everything goes.
- RISA: Star Trek memes and shitposts
Community rules (click to expand)
1. Follow the site-wide rules
- Instance-wide TOS: https://legal.lemmy.world/tos/
- Lemmy code of conduct: https://join-lemmy.org/docs/code_of_conduct.html
2. Be civil
- Understand the difference between a joke and an insult.
- Do not harrass or attack members of the community for any reason.
- Leave remarks of "peasantry" to the PCMR community. If you dislike an OS/service/application, attack the thing you dislike, not the individuals who use it. Some people may not have a choice.
- Bigotry will not be tolerated.
- These rules are somewhat loosened when the subject is a public figure. Still, do not attack their person or incite harrassment.
3. Post Linux-related content
- Including Unix and BSD.
- Non-Linux content is acceptable as long as it makes a reference to Linux. For example, the poorly made mockery of
sudoin Windows. - No porn. Even if you watch it on a Linux machine.
4. No recent reposts
- Everybody uses Arch btw, can't quit Vim, and wants to interject for a moment. You can stop now.
Please report posts and comments that break these rules!
founded 1 year ago
MODERATORS
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.
Generally I would agree that anything can be made with a GUI with enough investment. But the point where diminishing returns don't give enough return on GUI investment are reached much sooner than a scriptable shell environment where a power user can extend it in ways that would only make sense for that power user or a very small number of users.
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.
Yeah, and doing this would take significantly longer to use every time than typing up a chain of commands in a terminal.
Linux users: Non tech savvy people? Yuck
Also Linux users: Everyone should be running Linux instead of Windows!
Put those two statements together and the logical conclusion is that Linux users simply want everybody to be tech-savvy (although I'd use a different term: computer-literate). What's wrong with that?
Not everyone has the same interests. All car people would love everyone to be car people. All bikers would like everyone to ride bikes. The difference is that you pretty much need to be interested in computers to run Linux.
It's not about having the same interests; it's about the fact that the single distinguishing factor between a computer and any other mere machine is its ability to be programmed, and you therefore don't really know how to use a computer unless you can create novel workflows to solve your own novel problems. If you can't script, you aren't literate in the 21st century.
It's funny you should use those particular examples, (and not just because they also happen to be things I'm particularly passionate about).
In particular:
If you live somewhere that's built wrong (i.e. is car-dependent) and you can't drive, you're homebound. It's not about being a "car person;" it's about the skill being necessary to function.
Conversely, places that aren't built wrong are precisely those that facilitate cycling as a matter of design and policy. It's not about what "bikers would like;" it's about what empirically works best for a functioning city.
Honestly i dont think any of my friends or family can script any thing.
I used to examples because in both cases it's things you can do without it being an interest to you, you do it out of convenience, no need for a deep analysis, I could have said people who love camping would like everyone to love camping, it would be the same thing.
And just like those things, people use computers out of convenience and it's perfectly acceptable that some people don't have a deep interest in them and therefore wouldn't be interested by an OS that requires a deeper understanding of computers to make it work.
No, they're things you have to do without it being an interest to you; you do it out of necessity.
And that's exactly my point: you have to know how to, if not "program," at least chain functional components together into a workflow, if you are to be considered computer literate. IDGAF if you're using Linux or not; that applies equally to folks using Windows or MacOS too. Just like how the concept of (regular) literacy requires being able to write, not just to read, the act of using a computer is inherently one of creation and synthesis. If you're not doing that, you're merely consuming content.
You don't get the point at all...
No, going biking around the lake on the weekend isn't a necessity, driving your car instead of taking the bus isn't a necessity and no I'm both cases you don't need to understand the mechanical intricacies of the bike or car to do it. You're over analysing for no reason.
And no you don't need to be computer savvy to use a computer if you use an OS that's simple and automates tasks like updates and not everyone wants to understand computer enough to do those tasks manually, hence me pointing out Linux users spitting on people that aren't good with computers while also saying that everyone should use Linux, which requires being good with computers.
My 90 years old grandma got her first computer at 80 and she couldn't tell you how to plug a mouse in it, it doesn't prevent her from using it to check Facebook and get emails!
Nobody capable of defining an algorithm in a visual flowchart like that isn't also capable of doing it in a CLI (or at least, in text in general -- writing a script). It's thinking through what you want to happen that's the hard part; expressing it in the UI is trivial in comparison.
I've probably spent more time looking up how to access specific functions in a GUI than for CLI.
Wow, you created this program for creating shaders visually? That's impressive! You mind sharing the source code?
Things like that have been around for a long time. It was like two decades ago that I saw this shader scheme in softimage|xsi.
For implementing something like that, each node in that graph would have an array of inputs and outputs. Each of those would have a type like vector, scalar, colour, string. Then you only allow connections if the inputs and outputs match types (though you can also have conversion nodes or selectors that say pick the red channel of a colour to turn it into a scalar). Each input can be set to a constant value instead of connecting something else to it. Outputs don't need to be connected, which is mostly useful if a node has multiple outputs. Then each node has an evaluation function that takes all input parameters and maybe internal configuration parameters (though you might as well make everything an input param since there's no real functional difference) and uses them to calculate the outputs, which it then sends on to anything connected to those.
I'm not much of a UI guy but displaying it for the GUI would just involve drawing boxes or some shape for the node, then spaces for each of the inputs on the left side and outputs on the right side maybe colour code them by type, and lines running along the connections. Then just add the name and/or other visual information you want to display and positional information to let users move it around their work area.
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.
This right here, you can gui a single program, but with pipes we can chain nearly infinite programs. No way can you make a gui that is that flexible, I refuse to believe until I see it
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.
Most programmers are bad at UX but not nearly as bad as GUI designers are at understanding abstraction.
Most programmers are bad at both lol.
So true!!!
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.