Linux Project (RE: Linux vs. Windows and why win is winning!)

[Monty Harder]

>Monty,
>
>   I like this idea! Do you see a generic pop-up that allows the user to
>type in the option line (this would be for more advanced users), a generic
>pop-up that "builds" a list of options from a database, or separate pop-ups
>for each command?

  A combination of the first two.  Ultimately, an application package (rpm/dpkg/tarball) would have 
a file included that 
would be assimilated into the database. (Or more accurately, a pointer to the file would be 
assimilated) The dialog would 
have visual controls to set options, Help button (s) that call(s) up the manpage/ HOWTOs or 
whatever, and an Advanced 
Options field to enter any switches manually.  Ideally, as you click on radio buttons, the dialog 
would show you the 
command line it's building.  Probably have a Redirection tab on there as a separate entity for 
piping output elsewhere.

  I think the best way to implement the database assimilation is by defining a grammar in XML or 
similar, so that the file 
looks like this:

<command> 
 <name="ls">List Directory Contents</name>
 <opt="-1">Single Column"</opt>
 <opt="-a">Include Hidden Files (that start with ".")
  <help>By convention, files with a name beginning with a period are considered "hidden", as they 
contain information that 
is used by programs to store their configuration information, and are not often edited.  By not 
cluttering up the directory 
display, it's easier to find the files you want.  Checking this option shows those files, too.
 </opt>
 <opt="-b">Show Non-Printing Characters in octal</opt>
 ....
</command>

The <opt> tag could include parameters like
<opt="-d" type="alpha">Specify the device to print to:</opt> 
which would produce a field into which the user could type the value requested overriding the 
default of Boolean, which 
makes checkboxes.  Mutually exclusive options could be grouped inside <optgrp> containers, which 
would display the 
individual choices as radio buttons with a nice grooved border around the set.

Either that, or just use HTML <FORM> syntax and write a back end to massage the URL into something 
the command can 
understand. 

>>   No, but the ones that are rarely used would be buried 
>> deeper in the menus.
>
>Or, how about, turned off until the user turns them on in the menu
>configuration tool?

  That starts to sound like the MS2K theory of not showing all the menu options at first, then 
after a few seconds 
expanding the menu to include not-recently-used commands.  I turn that off right quick because I 
don't want things moving 
unless I move them.