Re: PROPOSAL: Automatic wrapping of CLIs with GUIs

["Ben 'The Con Man' Kahn" <xkahn cybersites com>]

On Mon, 15 Jun 1998, David Lutterkort wrote:

> Life would be a lot easier if one could just select the options one wants
> using a GUI and then run the command with these options. But writing a GUI
> for these small tasks seems like complete overkill. Unless the GUIs could
> be generated automatically.
> 
> This is exactly what the GUILE program 'wickel.scm' does: it takes a formal
> description of all the command-line switches and environment variables for
> a certain command and produces a complete GUI from this description. The
> description is very concise: for example, less than 90 lines for all the
> options that enscript uses.
> 
> I think this idea could be expanded to 'Active Manpages', where the help
> comes from tooltips and help texts of a GUI and one can at the same time
> learn what the options for a command do and set these options to
> appropriate values. It might even be possible to generate the information
> necessary to construct the GUI from SGML-source, so that info-file/manpage
> and GUI can be created from the same source. (Disclaimer: I know next to
> nothing about SGML)
> 
> But before I put a lot of work into this idea, I would like to hear
> people's comments on it. I have written a preliminary implementation of
> this idea (in GUILE). I put this and some screenshots on the page
> 
> <URL: http://www.cs.purdue.edu/homes/lutterdc/software/wickel.html>
> 
> So, here are some of the questions racing through my head: Would this be a
> useful program ? Would anybody use it ? What commands would you wrap in
> particular ? Is GUILE/Scheme the right language ? Would a compiler that
> translates GUI descriptions to C be useful ?

	Whoa!  Now that's a busy dialog box!  I get dizzy just looking at
that thing.  My first thought as a user would be to close the dialog and
RUN.  My thoughts?  Well, I think this is the wrong way to go, and I can
explain why. 

	Command line tools are powerful *NOT* because they have lots of
options.  In fact, I believe that the fewer the options a command
requires, the better.  (Who can remember them all?)  Instead, the power of
most command line programs are: speed, and connectivity.  

	If you want to copy a file in Windows from
\Windows\Media\Music\Punk\80s\catalog.db to 
\Program Files\HTTPd\pages\media\music\misc you have to browse through
dozens of GUI windows.  Even in a tree view things are complex.  But it
isn't that hard on the command line.  SPEED is important.  (Not to mention
TAB completion!)

	Connectivity is also important.  If I want to know all the unique
hosts who have seen my new web page, which I installed last week, this
ISN'T a problem.  I just have to link all the small command line utilities
together to the output.  

	Your program does neither of these things.  The enscript example
is interesting for a number of reasons:  It wraps around a program which
most people use rarely.  Such programs are ripe for GUIization.  Most
people use it by itself and not in a pipe.  (Although I'm fairly sure you
can use it this way.)  It is something which other GUI programs might like
to make use of.  (So we have GUI connectivity.)  And, it takes care of a
program which requires different options for most jobs.  (So people are
likely to need to look up the man page.)

	However, here are the flaws in your design so far:  The options
are just splayed on the screen.  No thought to the too busy factor.  Only
important, often changed options should be displayed to the user.  (Or
they should be displayed in a way which hides lesser used options...
Pulldown menu?)  Maybe a tree view would be better?  (But would have to be
updated to show current defaults.)  Also, I don't see a way to save
favorite formats.  (Named settings:  Work Documents, Memos, etc.)  

						-Ben

------------------------------------ |\      _,,,--,,_  ,) ----------
Benjamin Kahn                        /,`.-'`'   -,  ;-;;'
(212) 924 - 2220                    |,4-  ) )-,_ ) /\
ben@cybersites.com --------------- '---''(_/--' (_/-' ---------------
 If you love something, write it in C; if it compiles, it is yours; 
                     if it doesn't, it never was.