[sword-devel] Re: GUI interfaces
Wed, 19 Dec 2001 22:25:03 -0600
On Wednesday 19 December 2001 15:24, Stuart D. Gathman wrote:
> GUIs are nice. Their benefit lies in making the abstract appear
> concrete - visible and audible in todays technology, more in
> tomorrows technology.
> However, GUIs have a serious drawback. They require a warm body to
> operate them. All too often, I struggle with anger because some
> utility is available in a GUI interface only. This means some poor
> soul has to sit in front of a screen somewhere and click a mouse
> and/or keyboard until the task is done, when they could be home
> with their family. Countless hours are wasted with GUI chores that
> could be automated if only a command line or other programmatic
> interface was provided.
More than likely you encountered a GUI app written by a command line
coder. Not too intutive and not mindful of standard mouseing rules.
BTW, doesn't your 'warm body' operate the keyboard on the command
line as you type in the utility name and parameters? :)
I understand what you are saying, though.... gui-less utilities allow
unattended batch processing, for example. I use that approach all
the time. But, to my users, it is just another app activated by
clicking a mouse. They don't write the scripts nor do they care
about the utility. The job is what counts. For example, to
replace Win98E running the Wildcat BBS, I wrote one bash script, one
page long, and two python scripts, also one page each. The bash
script is what is executed when the user logs into their account. and
it restricts their activity to three tasks, or logging out. The two
python scripts automate two repetative manual processes that the BBS
admin does. Both python scripts are accessed via desktop icons that
the BBS admin clicks on. Both scripts could have been coded as
exposed methods of some resident object supplyling services and also
triggered by a desktop gui, but the required processing and data
movement was cut and dried. Sound familiar?
I've been using commandline utilities since 1978. The biggest
objection is that there are so many, they are obscure, and each have
their own set of switches (parameters), and none are standardized as
to what switches do what, except that either -h, --h, -help or --help
calls up some form of help. Frankly, as I got older, I got tired of
trying to remember parameters, switches, etc..., and inevitably one
loses the manual, if there ever was one, that explains them all.
When I got into Linux four years ago the most popular coding tool was
emacs, or xemacs. I got O'Rilley's book and after a couple of
chapters grasped the number of pluggins and switches that are
associated with each one. I realized that, having only 5 to 10
activing coding years remaining ahead of me, there isn't enough time
in life to endure such nonsense. GUI apps are standardized far
better than commandline apps are, and the well designed ones are
intuitive. The general user can move from app to app and never have
to consult a manual on mouse clicks. Coders writing GUI apps who
short-circuit this design principal are shooting their apps and
themselves in the foot. A commandline app is never intuttive,
unless you were the coder that wrote it.
> Microsoft's solution to this problem is a programmatic interface.
> Good Windows programs include a DDE or COM interface which is
> automatically available to Windows aware scripting languages.
> (This is where the Windows term "automation" came from as in "OLE
> automation".) The common unix solution to this problem is to
> provide a command line interface to the program.
The command line is not like Dynamic Data Exchange or Object Linking
and Embedding, later expanded to become ActiveX, etc.... A script
composing a shell program, ... maybe. Scripts are not event driven
like GUI interfaces are. Part of the 'dynamic' is the user, for
example, seeing clues in the data returned from, say, a remote
server, that causes him to mouse a particular GUI control that
triggers a particular event, out of many, causing the data to be
moved, processed, returned, destroyed or what ever. Such dynamic
interaction is not possible with commandline utilities unless the
'warm body' types commands that pipe data to files or does a screen
capture, etc... Object linking was created to allow an object to
reuse code present in exposed methods of other objects.
GUI interfaces, of course, are not procedural, because the coder
usually doesn't know in advance in what order events will be
triggered, except in certain limited ways.
> Command line utilities are not valuable because they are "friendly"
> to the casual user (they aren't). They are valuable because they
> are easily integrated with other programs in a way that does not
> require user intervention.
That they are not 'friendly' is why they are dying, no matter how
useful they've been in the past. When it was only academics and
geeks using them, and they were the only game in town, there was no
other choice. The number of people who are impressed by geek
knowledge of utility apps and their parameters is rapidly dwindling.
> How does this relate to Sword? Well, Sword is currently available
> to C++ programs. There should be alternate interfaces for other
> tools. A simple command line tool to quote a verse by reference or
> output a concordance like list of references given a search key
> would be handy for a scripted web page or editor macros. A C
> interface would be more easily wrapped for script languages like
> Python or Perl. A command line tool would also let you search the
> Scriptures on a 4Mb 386 in console mode (although an ncurses
> frontend would be nicer for that).
Diatheke does that. A curses version by Richard Holcombe also
exists, but it has had less than 100 downloads in the last 9 months,
which probably explains why Richard isn't too active right now. The
last work was on 0.16 on 2-17-2001. I've noticed a lot of older
geeks talk about the 4MB 386 as if there were a huge, unexploited
market for software that would run on them. There isn't. If those
boxes haven't been run the dialectrics in their capacitors have begun
to or have dried out. If they are being run then their component
MTBF limits have been passed and they are in need of constant repair
from a pool of parts that are drying up. No one makes 386 stuff
anymore. Few people write for it. Even third world countries won't
settle for them. Would you be happy with a model T when everyone
else is driving a 2001 Saturn? Even my brother, Dennis Malepi, in
Botswanna is using Pentiums and acquiring them for the Christian
school he is building there.
That BBS box I told you about is a P200 with 64MB of RAM and two 1GB
HDs, running SuSE 6.4. It replaced a P450 with 128MB running Wildcat
because the higher ups didn't think Linux could do the job and they
didn't want to waste a 'good' box on what they considered an
experiment. That was 16 monhts and ZERO crashes ago. The WinXX
'solution' averaged a couple of crashes a day and couldn't be left on
overnight to allow after hours downloads from electronic taxpayers.
The clerk that runs it says it is easier to use than the WinXX setup
and KDE1 is just as easy to use as WinXX. She says the P200 solution
runs about twice as fast as the WinXX solution.
Finally, if folks had to install Linux distros the way they did when
Slackware first came out...... Only the GUI install programs are
giving Linux a fighting chance in the desktop arena. GUI apps are
rapidly taking over sever control too. With will designed GUI apps
users do not have to give up power, either.
The reign of the command line has come to an end.