Re: PROPOSAL: Automatic wrapping of CLIs with GUIs

[lutterdc cs purdue edu (David Lutterkort)]

>
> On Mon, 15 Jun 1998, Ben 'The Con Man' Kahn wrote:
> 
> 	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. 
> 

I agree that the layout is not as good as it could be. But creating a nice
layout is not where I see the main difficulty in the implementation. The
main difficulty is coming up with a good way to capture enough information
about the command line options formally to be able to generate the GUI
automatically, with as little hand-added cruft as possible. 

But even with the way the layout works now, you are not forced to produce a
GUI as cramped as the ones I got on my web-page.

> 	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.  
> 

Agreed. But as a sad fact of life, most command line tools (especially ones
that merely display information) tend to have more options than anybody
would care to remember - and they _are_ useful.

> 	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!)

Navigating the file system _is_ difficult, and there's nothing stopping you
from using TAB completion in a file selection dialog (I think
gtk-file-selection already has that) 

> 	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.  

I am not trying to replace command line interaction, but only to make it
easier to remember _how_ to use all these commands. And adding some
interface to allow pipelining and redirection isn't very hard. It's an
addition I've been thinking about, too.

> 	Your program does neither of these things.  The enscript example

This is alpha and very sketchy.

> 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.)

I ususally use it in a pipe with psnup. But again, I'm trying to explore
how much of a GUI with extremely simple semantics (read values and concat
them to a string) can be generated automatically, without having to dive
into writing callbacks, packing boxes etc.

> 	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

If you look at the code from which the examples were generated (click on
the pictures in <URL:
http://www.cs.purdue.edu/homes/lutterdc/software/wickel.html>, you'd notice
that the layout is described on a few lines, and if you only want to have a
few options per page in the notebook, you're free to do that, e.g.

(layout
  (page "Everybody's favorite options"
     (vbox option1 option2 option3))
  (page "Extremely rare options"
     (vbox
       optionA 
       (hbox optionB optionC))))
	
but there is a trade-off between having too many pages in a notebook (which
is confusing, too) and cramping every page.

> 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

What's wrong with a notebook in which the pages are ordered according to
importance. 

> updated to show current defaults.)  Also, I don't see a way to save
> favorite formats.  (Named settings:  Work Documents, Memos, etc.)  

Good idea. 


David

--------------------------------------------------------------------------
You can lead a horse to water but you can't make him walk on it. G. Larson
You can lead a horticulture, but you can't make her think. D. Parker
--------------------------------------------------------------------------
David Lutterkort                  email:  lutter@purdue.edu
Dept of Computer Science          tel:    +1 765 494 4359
Purdue University                 http://www.cs.purdue.edu/people/lutterdc
W Lafayette IN 47907-1398         office: MATH 408
--------------------------------------------------------------------------