[sword-devel] Re: GUI interfaces

[Stuart D. Gathman]

Jerry Kreps wrote:

> I've noticed that while most distros, like SuSE for example, have a
> command line capability, usually through an xterm, they present the
> user with a GUI, mainly KDE and to a lesser extent, GNOME.   The last
> survey I saw showed KDE use among Linux users is above 70% and
> climbing.  Use of KDE by newbies is above 95%.  Apps based on QT and
> made with KDevelop are exploding in number.  QT's 'Signal and Slot"
> technology, as evident in KDE, KDevelop and the many apps written
> using the QT widget, is fueling the explosion.  Many of these apps do
> not wrap the old GNU utilities but provide methods as part of their
> object classes that possess equal or better capabilities.  In other
> words, as progress on KDE, QT, GUI and GUI RAD continues, command
> line utilities are being ignored by an increasing number of Linux
> users.  Newbies from WinXX who were never familiar with DOS will
> never become familiar with the Linux commandline, especially when
> they can solve their problems by clicking the mouse.   They have been
> contemptuously labeld the 'click and drool" crowd, but their behavior
> is rapidly acquiring majority status in Linux.  Someday, sooner or
> later, some distro is going to wonder why command line utilities are
> being included in the primary release and may offer them only on a
> secondary CD. 

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.

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.  

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.

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