Ubuntu QA:
BlogBrainstormPackage status
Log in
Ubuntu QA
The Ubuntu community has contributed 21986 ideas, 135057 comments, 2615221 votes
Idea sandbox Idea sandbox
Popular ideas Popular ideas
Ideas in development Ideas in development
Implemented ideas Implemented ideas
Idea #9988: GUI for CLI

Written by Tree MendUs the 18 Jun 08 at 02:01. Category: Accessibility. Related project: Nothing/Others. Status: New
Rationale
Graphic User Interface (GUI) for Command Line Interface with command options and including a "Help" function.

Situations :
1) Newbies uncomfortable with Command Line.
2) Tired of referring to manuals, manpages, info, net (for help).
3) People want to avoid typing errors
4) Easy to learn and begin to use

Much of the problem in using system commands would be radically reduced for Ubuntu users, if the "commands and their options"(& default settings) were readily available together in a GUI window. The window could include display for explanations/documentation/help.


Solution Path - How the present help and man pages can be used for a new GUI command maker ;

Most programs and utilities that use the command line also have a help file and or manual file.

The help files and manual files list the command options, and some of them tend to use similar formats for listing the command options and their usages.

It would be possible to have a program that ;
a) goes through the system looking for CLI type commends and programs,
b) looks up their help files and manuals (on the PC and optionally on the net),
c) reads the usages and converts it (if needed) into standard help files and manual layouts.

These standard layouts can then be read by a GUI front end to a command (invoked say by the command GUI interpreter followed by "-command name"), to compose and show ;
a) a window with the command as a title,
b) a line for the compounded text of the full command,
c) a list of options (that may be tabbed if there are multiple multi-choice options),
d) context sensitive help for each option,
e) "browse" functions to select files and folders for the command, recommended defaults,
f) and user customized options (with easy to understand assignable labels).


Eventual implementation ;

Writers, contributors, and even users, could help standardize the help files and man pages over time.
This is a process which may take time - but WILL "never happen" if it Never "will get started".

A list could be maintained of all programs that have been adapted/converted for use in this way. So it can be downloaded, and users can regenerate their utilities/programs. People who are looking for a couple of minutes to several hours worth of time they can spend helping Ubuntu, could look up the list of programs yet to be converted, and choose some help files/man pages to go through (maybe using a utility that helps with an initial best guess of the format).
Command and Program writers could be encouraged to write their helpfiles, man pages, documentation, to match the layout required for automatic reading by this utility.

If there is resistance to having a standard layout for help, man pages, docs, etc, then maybe a new text document layout could be made specifically for this, and independent of the others (even though it could be easily generated from them).

Various types of access ;

The programs (maybe by use of the list), could also be optionally added to a menu for system commands, scripts, etc in various categories, so they can accessed directly from the users menu, desktop, or any toolbar.

The list of programs could include information for the recommended location in the menu, and which ones are best grouped into which toolbars.

Also right click to menu in Nautilus.


Safety ;

In the case where users may be using command line utilities for such tasks as system maintenance, it might be handy to have permissions management built straight into the GUI, or at least a temporay "sudo"mode (which only allows sudo for the use of "that" respective program - gets requested for each program).
The user could be met with a prompt (e.g. "You have requested a program that requires 'Root' authority to use. Only use this program if you are confident that you know hat you are doing. You will be required to enter the 'Root' password.")


Window Layout ;

The window could have two types of layout. One for fully functional commands (the help and ma files all work properly to generate the window.
The other is for commands and programs that have not been converted. This window layout has basically a text line or two and an area for reading the help/manpage next or below. The user can copy and paste the command and options into the text line. But they still have the additional options to save their settings and assign a meaningful label.

[There is the possibility to allow the user to edit the help/man page in this window, to at least convert the section of info in the file that they need.]



Benefits ;

For those who like command line use, this makes no difference.
For those who want to get into their system form time to time, and would rather deal with familiarity rather than memory, this is very encouraging.
For those with no OS experience other than windows, this is a major reduction in a "con"(vs Pro) of not getting into Linux.

It also makes it much easier t

-24
votes
up equal down
Solution #1: Auto-generated solution of idea #9988
Written by Tree MendUs the 18 Jun 08 at 02:01.
Ubuntu Brainstorm was updated in January 2009. Since the idea #9988 was submitted before this update, its rationale and solution are not separated. Please vote accordingly, and if you have the necessary rights, please separate the rationale from the solution. Thanks!

Propose your solution

Attachments
No attachments.


Duplicates


Comments
Vadim P. wrote on the 18 Jun 08 at 02:42
Try Hotwire (http://hotwire-shell.org/).

nevermind85 wrote on the 18 Jun 08 at 03:24
I like your idea, tho I would try to re-write it again in a more clear and short way. Something along the lines of "Develop a GUI for man pages" with extra features like a built in shell or something... you get the point.

Tree MendUs wrote on the 18 Jun 08 at 08:53
@Vadim P.
Thanks for the pointer to Hotwire at -
http://hotwire-shell.org/

I hadn't seen it before.
From my quick read of it, it sounds more like a gui for the shell environment, somewhat like a file manager.
It may even generate a GUI front end for the the commands that can be accessed through it.

But I hadn't seen anything to suggest that it would make use on man pages, help files, or documentation, to automatically generate a window with GUI type selection of command options. Nor did it seem to mention some sort of collaborative or coordinated means for anybody to convert current program's and command's help/man pgs/docs to work.

@nevermind85

Thanks for the support. Unfortunately "clear" and "short" is not my forte. I try to be explicit and definitive. But I may have failed in that, here.

Thank you for breaking it down to an "essence" of ;
"Develop a GUI for man pages" with extra features like a built in shell or something

That is quite a clear statement.

But Although a GUI for the man pages is handy, and having an attached access to the shell is also handy, my idea is a bit more than that.

I have described the effect, because I thought the workings would be clear.
The idea that I am am proposing is that the man pages/etc could be used to generate the GUI interface.

The procedure would work something like ;

1) From the man page title and elsewhere, the command name can be assertained with confidence.

2) From within the files, the options can be discovered, and these can be sorted as to mutually exclusive or independent.
Use these to generate drop down list, list, radio button (how ever the user prefers to be shown such choices)

3) each option may have a range of settings, and each of these are likely to be mutually exclusive (but this could be checked also.
Use these to generate drop down list, list, radio button (how ever the user prefers to be shown such choices)

4) any options that required text entry, could provide a text entry box.

5) any options that required file selection could use a "browse to" function, or manual text entry.

6) Yes No options and Include exclude choices use a check box.

All of these get automatically generated from either existing files, or files that get edited as time goes by.

This approach changes the daunting task of rewriting programs to run in a GUI environment, in to the easy (nobody has to bother too much) task of writing something that helps the GUI environment use commands.


Tree MendUs wrote on the 31 Jul 08 at 22:04
Please view a related idea and vote:

Idea #10194: GUI for CLI (command line) with Piping features like the GUIs for audio piping.
http://brainstorm.ubuntu.com/idea/10194/

Tree MendUs wrote on the 9 Aug 08 at 12:31
Idea for additional feature - for automatic menu of system commands.

Program to scan the system for commands and utilities that are not in the menu, look for their command options, look up some lists that have been researched - to determine what type of command they are (file manager, configuration utility, diagnostic, etc), and generate a drop down menu for the GUI with these commands automatically included.

Endolith wrote on the 22 Aug 08 at 13:46
This will never happen until Apple does it. Then it will suddenly be a good idea.

Tree MendUs wrote on the 7 Sep 08 at 08:34
Thanks Endolith,

Apple is Apples.

But may be it's ideas like this which have the bite?


Endolith wrote on the 8 Sep 08 at 03:24
I'm being sarcastic. Anything to make the command line unnecessary or easier to use is a GREAT idea, but many Linux developers are stuck in the past, and refuse to innovate.

After Windows or Apple does something, it suddenly changes in their minds from a bad idea to a good one, at which point Linux is in a rush to play catch-up.

joerlend wrote on the 6 Oct 08 at 13:17
I don't understand why it would be better to make a special program for "CLI"-help instead of just using the HTML-files. -1

Tree MendUs wrote on the 8 Oct 08 at 04:34
1) Endolith.
I knew you were being that way.
I am referring to the "chomp" in the logo.

Thanks for the support


2) Joerland.
The html files (or docs, or manpages) make the help information available.

But "availability" is not the same thing as "accessibility" or "usability" (or even "understandability").

To be able to read the help (in what ever form[s] it takes) from within the program, allows for automatic access.
No other windows need to be opened to type in an address or command to call up help (and the user would have to be aware what form the help is in, or else guess).
Context sensitive help can be used.

The command syntax information in the help can be used within the program to help correct some (may be all) typo errors. (e.g. missing spaces,dashes, commas, numerical values, etc)

The command syntax information in the help could even be used by the program to construct choices (radio buttons/drop down selections, check boxes, etc), for a GUI panel for the command settings.

It's all in the one (integrated) window/package.
The mouse clicks to do actions are noticeably reduced, the user confidence is increased.


Endolith wrote on the 8 Oct 08 at 16:39
People don't get it. Bash is not a user interface; it's a programming language.

Good user interfaces don't need manuals or help pages. They are intuitive, usable, and discoverable. Users shouldn't be required to read through much of anything to interact with their computers and get things done.

There's nothing wrong with the bash programming language, but it makes a really horrible user interface.

FrisoSeyferth wrote on the 15 Mar 11 at 03:21
(here's my point, i already wrote this before i saw it on brainstorm)


Although we've come a long way with a myriad of graphical system configuration tools, web based alternatives etc. when push comes to shove and you have a problem, you will have to go into the (dreaded) command line interface. And if it couldn't get worse, even the prompt of most shells are intimidating, sporting colons, slashes, dollar signs etc.

What if you could hover your mouse over the terminal window and a number of tasks would fade in. Selecting tasks and eventually commands, with every option available through this point and click interface, allows novices to explore without reservation (the feeling that you don't really understand all of Linux - i had that for a long time) all the options while the command line interface/terminal in the background 'magically' types the choices into a command line with options and parameters.

This idea has more or less been touched on now and then, but none of the projects never seemed to have catched on. What comes closest is the Composite User Interface (http://linux.pte.hu/~pipas/CUI/). But it never developed beyond a rudimentary example.


A shell running zsh that uses graphical interface to generate commands, bridging intuitively the command line and graphical administration world. The Gnome Command Interface (http://www.stanford.edu/~dramage/gci/) feels more like the Powershell, as a structured way of accessing all elements of the modern desktop in a discoverable manner.


This idea has been already pioneered by CUIterm. Composite User Interface, but was never developed further. Anthias (http://anthias.sourceforge.net/index.html) is another example.

I don't think it's possible to get away with 'black-boxing' the operating system and 'hiding' the command line completely behind GUI interfaces. The command line is here to stay, also for desktop linux. (install a binary driver from nvidia, for instance, or repair a package, stuff that any desktop linux user might encounter.)


Post your comment