Re: GUI vs: CLI (was: Shell command in VB6)
From: Michael Mendelsohn (keine.Werbung.1300_at_msgid.michael.mendelsohn.de)
Date: 04/08/04
- Next message: Will: "Is there a cross platform language ? PC - Mac - Unix/Linux"
- Previous message: carl mcguire: "Re: A very quick, informal survey"
- In reply to: blmblm_at_myrealbox.com: "Re: GUI vs: CLI (was: Shell command in VB6)"
- Next in thread: Michael Mendelsohn: "Re: GUI vs: CLI (was: Shell command in VB6)"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Thu, 08 Apr 2004 13:08:00 +0200
blmblm@myrealbox.com schrieb:
> Programmer Dude <Chris@Sonnack.com> wrote:
> >"MSCHAEF.COM" wrote:
> >> If you make the dialog box simpler by breaking it up into
> >> multiple sub dialogs, you've just made it more difficult to
> >> discover your options, which was the point of the GUI in
> >> the first place.
> >
> >If the app is so complicated that it takes multiple sub dialogs
> >to configure, then I can't imagine the CLI situation is going
> >to be any prettier. Further, unless you use that complicated
> >app *frequently*, your choices are likely hitting the manpage
> >or using the GUI.
>
> Well .... Unless the command you used for that CLI makes its way
> into your .bash_history or similar file.
>
> IMO one of the pluses of a CLI is that however obscure the
> incantation to achieve a particular effect might be, once you've
> figured it out it's easier to capture for later use and/or share
> with someone else.
The key word here is "file".
If you have too many options to a CLI command, then your model of that
function needs to change: you do not have a function that operates on a
single input any more, the options have become an input in its own
right.
It is obvious that you need a second input file with (e.g.) awk if you
want to achieve complex tasks (the script); there are also some
non-scripting commands that can use a .rc file for their options. This
input file can usually be overridden by other options placed on the
command line after its inclusion. Wget would be an example of such a
program.
The GUI then is your text editor; if you have a base .rc file that
contains all the options #commented out, you use your text editor to
move to the options and uncomment those you need. The workflow is very
similar to that of the proposed GUI wrapper, where you'd TAB and uncheck
boxes.
The advantage in using a text file is there's a transparent way to save
your work, reuse, reload and edit it, you can use your favorite GUI (=
text editor) to edit, you can yourself make a subset of the base file
(i.e. move the options you don't need to the bottom of the file or just
delete them), and you can have a set of files that do the things you
commonly need and make common modifications using a handful of
additional commandline options after you've included the .rc file (i.e.
you write your "default" behaviour into a file and modify that).
All of this can be done by the GUI as well (including the saving and
loading of parameter sets). The disadvantage is that when the command is
updated to take more options, the GUI is out of date; the text editor
won't be. ;)
Oh, and if there's a command line program that does not support a .rc
file, you can of course write another CLI app that reads a .rc file and
calls it - the wrapper need not be a GUI program at all :).
Michael
-- Feel the stare of my burning hamster and stop smoking!
- Next message: Will: "Is there a cross platform language ? PC - Mac - Unix/Linux"
- Previous message: carl mcguire: "Re: A very quick, informal survey"
- In reply to: blmblm_at_myrealbox.com: "Re: GUI vs: CLI (was: Shell command in VB6)"
- Next in thread: Michael Mendelsohn: "Re: GUI vs: CLI (was: Shell command in VB6)"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
