skeezix said:
2) total newbies doing stuff -- use the GUI, don't try the command line at all, it'll just piss you off.
If the use case is somethign like .. "we want to apply various tweaks, that are not provided for in the GUI", then the _real_ question is not "wheres a command line helper" but is instead "where in the GUI can o I do _xx_" or "can we write a twerak GUI, like so many other OSes have?", that is a library of wteaks that can be applied/removed on demand.
All I'm trying to do is to find the most painless solution to a problem.
The problem is this: Many useful things on the Pandora can only be done by command line.
Sure, in an ideal world, there would be a GUI to cover all of those things.
But we've already seen, such as for example when I proposed
a GUI for changing Pandora's input assignments (which would have with one stroke fixed the situation with the many PNDs that have badly-mapped keys), that devs are busy, and any proposals we make must be balanced against the reality that devs do not have infinite time to do what is ideal. The Pandora is mostly a volunteer project, and making comprehensive, intuitive GUIs takes a lot of thought and time. Plus, Linux devs have little use for GUIs themselves, because they prefer the command line, so they don't have much motivation to work on them.
And for good reason - the command line is powerful and perhaps more logically laid out than many GUIs. Unfortunately, it also has a high entrance barrier, a bit like how in the Middle Ages anyone who wanted to read the Bible had to learn to read Latin first.
Okay, maybe I'm stretching a little, but let me run with this analogy a bit. A select few know the special language, and based on their knowledge, ask the common folk to carry out instructions that the common folk do not understand. If you ask for help with the Pandora, the answer will pretty often be "type this into the terminal". For example, when I asked how to get the information that is provided in Microsoft Windows by the Task Manager,
chris_c told me of several terminal commands. When I had trouble getting a USB device recognized, slaeshjag asked me "
Does dmesg identify it?" - so I had to Google for what dmesg was and what exact command would work for what I wanted to know. You cannot even SEARCH FOR A FILE in the file manager, but you can do it in the terminal.
Clearly, unless devs
enjoy being the gatekeepers, it is better for everyone if the Pandora's users become more self-reliant so they can do what they want themselves and not ask devs to do it for them. Anything that will make the transition smoother is a positive thing. My proposal is a bit like a
translation project, translating the special language to the common language that people will understand. And it will do it on-the-go, like Babelfish, only I imagine it will be more precise because programming languages cannot afford to be as vague and fuzzy as human languages.
Judging from what mindlord has said, much of the raw material needed for this program already exists. If pressing TAB twice allows one to see a list of commands that start with a letter, then obviously Linux keeps a full listing of all the words in this terminal language somewhere. If typing "--help" will bring up an explanation of the command, this means that Linux also has dictionary definitions for all these terms already.
The main "innovation" in my GUI proposal, then, is simply to speed up the process significantly by allowing a user to quickly mouse-over all the possible definitions at once, then go back and try another "branch" that a command could take.
OF COURSE any prudent user will first Google the command he's trying to build to see if it's dangerous. The point is that by laying out all the options, it makes it easy to see what CAN be done, and you don't have to study a new language all at once but can learn it gradually, as you slowly try more and more complex things.
Skeezix, your argument AGAINST making knowledge accessible is frankly a bit strange to me. It is the same as the one the Catholic church was making for not translating the Bible to local languages.
I know a little about internal combustion engines, but I should not take my cars engine apart
What if while you were doing that, for every part you considered removing or adding, a definition popped up telling you what would happen if you did that? I bet you'd be a lot less likely to make a mistake.
The only reason I can think of to have a GUI for CLI commands is a device like the iPhone where it has no keyboard and it makes input easier. Anyone that thinks differently should open up a terminal window right now and type "rm -rf /", and if they don't understand why it is a bad idea before they should do after.
What's your point? Anybody can open a terminal and type that ALREADY, no?
The difference with my proposal is that by being able to see the definition of each term by mousing over it, the user will be able to to AVOID doing dangerous things.
It makes no sense to make a GUI to type cd/ls for you in a terminal window, unless you don't have a keyboard.
As I said, if mindlord is correct, all of this is already possible by pressing double-tab and --help in the terminal itself. My only innovation is making it quicker to go forward and back between possible branches of a sentence.
In my mind... I see it as a happy medium between gui-only and standard CLI... with the way ESN is suggesting, it would be "doing the work for you" while explaining the work to you, essentially... so imagine a pillar in the middle of a chasm you are trying to cross... makes crossing that chasm a little easier since you don't have to leap the full distance across, but half the distance twice... just my assumption of it all though...
Yes, exactly.
Basically, I wonder if there's a way to keep all the power of the Linux command line, while making it easier for new users to know what they can do.
