RE: [gtk-list] Re: PROPOSAL: Automatic wrapping of CLIs with GUIs

["O'CONNOR, Steve" <SOCONNOR baea com au>]

My suggestion is that you just keep it simple.

# find -type <F1>
   in your program, trap the F1, 
   do a 'man' on the first word (find in this case), grab the output and
display it in a popup
   window.

If the offending program is properly installed, it should have an
available man page. If it does not, you might suggest that the user run
<command> --help or something. Failing that, you could search for a
README file that lives in the same directory as the executable and
display that ...
   
In the same way that the function X^n + Y^n = Z^n has no whole number
solutions for values of n > 2, there is no definitive way to get the
command line arguments for any given UNIX program. 

Keep in mind, that after a human brain has resorted to reading the man
page to find the meaning of a particular option ... after reading it 3
times it will be remembered for many months. If read and used 7 or more
times, the human brain will automatically place that option in long-term


> -----Original Message-----
> From:	nelson-gtk@crynwr.com [SMTP:nelson-gtk@crynwr.com]
> Sent:	Thursday, 18 June 1998 12:45
> To:	gtk-list@redhat.com
> Subject:	[gtk-list] Re: PROPOSAL: Automatic wrapping of CLIs with
> GUIs
> 
> Tim O'Neil writes:
>  > > Would it be possible for the freeware community (pushed by GNOME
>  > >developers) to come up with an application level way of allowing
> this ?
>  > >
>  > >Kate
>  > 
>  > If you feel strongly about such a program, I would say write it.
>  > Then see if it takes hold. Its the only way, really. You never
>  > know, it just might turn out to be The Killer Utility.
> 
> Been there, tried that, didn't get very far with it.  My start at a
> database of option descriptions is at the end.  Unfortunately, I
> started with one of the most optionable programs: ls.  And here's the
> gist of the messages explaining the idea, to and from people.  People
> were basically dubious, not of the value of it, but of the probability
> of my succeeding with it.  ">"-quoted text is written by other people,
> 
> left-margin text is written by myself.
> 
> First, the introductary message, followed by the responses, sometimes
> with additional explanation by myself.
> -russ
> 
> ----------------------------------------------------------------
> 
> I'm wanting to make Unix more usable.  Idea is that programs that run
> programs (like a shell, or a GUI) can query the program about how to
> run it, and get the information back in a structured format.  Also be
> able to ask the program to do string completion.  Obviously you have a
> chicken and egg problem, so the shell/GUI can fall back to a database
> that describes the program's options.
> 
> ----------------------------------------------------------------
> 
>  > I recall a long discussion about this a few years ago.  I think it
> was in a
>  > GNU group and centered around bash and getopt_long().
>  > 
>  > The conclusion was that it would require
>  >     - a database, which would be constantly out of data, or
>  >     - a magic program option, which wouldn't work with existing
> binaries, or
>  >     - a defined structure in the binary much like the existing
> getopt()
>  >     string.
>  > 
>  > Option #3 had its own problems, but seemed to be the best choice at
> the
>  > time.
> 
> ----------------------------------------------------------------
> 
>  > I don't think I fully comprehend the gist of this.  If you could
>  > explain some more what would actually happen I could make a more
>  > educated assessment.
> 
> The idea is to describe the command-line options of the program in a
> structured manner, so that an external program can build up a valid
> command line, and can describe the meaning of those options to the
> user.  So that, when I'm typing a ``find'' command, I can say -type
> <tab>, and get a listing of the valid types and their meanings.
> 
> The net result would be that the shell (be it text or gui), would
> automagically be a menuing shell.  Hit <tab>, and you see a listing of
> all the commands on your path, and a synopsis of what they do.
> 
> Essentially, you could write one GUI program to use this information,
> and it would transform all Unix programs into graphics programs.
> 
> It doesn't matter where this information comes from.  It could come
> from a standard --describethyself argument, or it could be encoded in
> the binary, or it could come out of a database.
> 
>  > We also try to put wmconfig files in packages like lynx so that
>  > it gets started with xterm -e.  Top will have one as well.
> Obviously
>  > this doesn't solve all problems, though
> 
> Right.  My plan doesn't require or inhibit X.  But neither does it
> deal well with text-mode interactive applications.  All it's designed
> to do is be able to build up command lines, but do so in a manner
> that's still useful once you know how to do it yourself (but have
> forgotten which character to give to find's -type option).
> 
> Kind of like a man page that you don't need to run man to get.
> 
> ----------------------------------------------------------------
> 
>  > Ah yes, Twenex-stype argument completion.  This suggestion has come
>  > up now and then over the past 20 years, and the conclusion has
>  > always been that it's not the solution to any pressing problem.
>  > For really naive users, you're better off with a menu shell of some
>  > sort.  Once people get a little more sophisticated, there's a lot
>  > to be said for the 100% consistent syntax and globbing behavior we
>  > have now rather than the capricious expand-sometimes rules of
>  > systems like MS-DOS.
> 
> Yes, I'm thinking that this would be of most use to the naive user,
> because it would act as a menu shell.  But it would also be useful to
> the sophisticated user who forgets, for example, what characters are
> valid following find's -type option.
> 
> It would also transform the problem of building a Unix command from
> recollection to recognition, the latter being a much simpler problem.
> 
> The idea was mostly prompted by the reaction of a group of
> click-n-drool NT sysadmins.  It was a mixture of pity, grudging
> respect, and fear, as they watched me issue command after command from
> memory.
> 
> ----------------------------------------------------------------
> 
>  > 
>  > Let me try the "why re-invent the wheel" answer
>  > 
>  > Get a copy of Linuxconf and the classes therein. Also talk to
> Caldera who
>  > are sponsoring a related project
> 
> Not what I was proposing at all.  My plan was to give a shell access
> to information about a program's options.  The idea is that the same
> information could be used to create a menuing shell for beginners, or
> a completion shell for experts.  Let's say that I'm typing a find
> command, and can't recall what the characters are that follow the
> -type option.  I just hit <tab>, and get a listing of the options, and
> their meanings.
> 
> This information about the program would be retrieved by whatever
> means necessary, by a combination of a database, parsing the --help
> output (for those programs for which the output can be parsed),
> modifying the binaries to include the information, or modifying the
> programs to generate it when given a --describethyself option.
> 
> ----------------------------------------------------------------
> 
>  > Hi,
>  > 
>  > I'm not sure whether it can be done.  But it would be great to have
> it (I
>  > very much like the way I can just press "?" anywhere on a Cisco
> command 
>  > line...).
> 
> ----------------------------------------------------------------
> 
>  > Sounds like a good idea to me...I'm not sure how the best way to
> make
>  > it work is, but it sounds like a good idea.  I'm certainly sick of
>  > looking up how 'find' works all the time.  :-)
> 
> ----------------------------------------------------------------
> 
> And finally, here's the database format I had consed up.
> 
> 
> # string==/value/documentation/
> # if a string appears multiple times, it's one of the choices.
> # A value may contain another string referenced by $stringname.
> # A string may be repeated zero or more times if it is suffixed with *
> # every command must define a ``command'' string.
> 
> command==/ls $option* $file*/List information about the FILEs (the
> current directory by default). Sort entries alphabetically if none of
> -cftuSUX nor --sort./
> 
> option==/-A --almost-all/do not list implied . and ../
> option==/-a --all/do not hide entries starting with ./
> option==/-B --ignore-backups/do not list implied entries ending with
> ~/
> option==/-b --escape/print octal escapes for nongraphic characters/
> option==/-C/list entries by columns/
> option==/-c/sort by change time; with -l: show ctime/
> option==/--color$when*/control whether color is used to distinguish
> file types./
> when==/=never/Never use color/
> when==/=always/Always use color/
> when==/=auto/Use color sometimes/
> option==/-D --dired/generate output designed for Emacs' dired mode/
> option==/-d --directory/list directory entries instead of contents/
> option==/-F --classify/append a character for typing each entry/
> option==/-f/do not sort, enable -aU, disable -lst/
> option==/--format=$format/Listing format/
> format==/across/same thing as -x/
> format==/commas/same thing as -m/
> format==/horizontal/same thing as -x/
> format==/long/same thing as -l/
> format==/single-column/same thing as -1/
> format==/verbose/same thing as -l/
> format==/vertical/same thing as -C/
> option==/--full-time/list both full date and full time/
> option==/-G --no-group/inhibit display of group information/
> option==/-I --ignore=PATTERN/do not list implied entries matching
> shell PATTERN/
> option==/-i --inode/print index number of each file/
> option==/-k --kilobytes/use 1024 blocks, not 512 despite
> POSIXLY_CORRECT/
> option==/-L --dereference/list entries pointed to by symbolic links/
> option==/-l/use a long listing format/
> option==/-m/fill width with a comma separated list of entries/
> option==/-N --literal/print raw entry names (don't treat e.g. control
> characters specially)/
> option==/-n --numeric-uid-gid/list numeric UIDs and GIDs instead of
> names/
> option==/-o/use long listing format without group info/
> option==/-p/append a character for typing each entry/
> option==/-Q --quote-name/enclose entry names in double quotes/
> option==/-q --hide-control-chars/print ? instead of non graphic
> characters/
> option==/-R --recursive/list subdirectories recursively/
> option==/-r --reverse/reverse order while sorting/
> option==/-S/sort by file size/
> option==/-s --size/print block size of each file/
> option==/--sort=$sort/sorting order/
> sort==ctime -c
> sort==extension -X
> sort==none -U
> sort==size -S
> sort==status -c
> sort==time -t
> option==/--time=WORD/atime -u, access -u, use -u/
> option==/-T --tabsize=COLS/assume tab stops at each COLS instead of 8/
> option==/-t/sort by modification time; with -l: show mtime/
> option==/-U/do not sort; list entries in directory order/
> option==/-u/sort by last access time; with -l: show atime/
> option==/-w --width=COLS/assume screen width instead of current value/
> option==/-x/list entries by lines instead of by columns/
> option==/-X/sort alphabetically by entry extension/
> option==/-1/list one file per line/
> option==/--version/output version information and exit/
> 
> -- 
> -russ <nelson@crynwr.com>  http://web.crynwr.com/~nelson
> Crynwr supports Open Source(tm) Software| PGPok |   Freedom is the
> primary
> 521 Pleasant Valley Rd. | +1 315 268 1925 voice |   cause of Peace,
> Love,
> Potsdam, NY 13676-3213  | +1 315 268 9201 FAX   |   Truth and Justice.
> 
> -- 
> To unsubscribe: mail -s unsubscribe gtk-list-request@redhat.com <
> /dev/null