A primate's worries about Unix and GNOME

["David G. Wonnacott" <davew-gnome triluminary cs haverford edu>]

As a primate, I always considered "the tool-using approach" to be the
biggest plus of the command-line unix interface.  I think I enjoyed
constructing a new script by tacking together sed, cut, bc, and paste
at least as much as a chimp enjoys making a tool to collect insects by
stripping the leaves off a twig.

On a more serious note, I have worried for some time that the
introduction of tools that are gui-based, rather than text-based,
might compromise this tool-using approach.  Note that there is no
fundamental conflict between the two, as evidenced in SmallTalk/80
(and, I think, the more mature Lisp environments).  You just have to
get in the habit of creating tools that can communicate with other
tools as well as the user (this is not always easy).

Unfortunately, I don't know enough about the internals of the GNOME
software, or CORBA, to know if these worries are justified.  So, in
hopes of finding reassurance, or at least raising this issue, I ask:

1) Does CORBA or anything else make it easy to build tools that
   provide both a software interface and a GUI?

   Suppose I were writing an interactive desk calculator; Perhaps I
   have a function in my code to calculate square roots (please
   imagine that this was not already provided in the standard math
   library, so I can keep my example simple).  How much extra work do
   I need to do to ensure that authors of other interactive tools can
   make use of the core functionality that underlies my application?
   (That is, how can I let them call the square root function without
   getting involved in my user interface to it?)

   I can imagine several options, listed here approximately in order
   of decreasing convenience:

   a) Other programmers can just call my function unless I have taken
      steps to hide it from them (this is available in many systems
      that retain symbolic and type information at run-time, such
      SmallTalk or Lisp).  I do not expect to see this in GNOME, but I
      thought I'd list it for completeness.

      In this case, providing a software interface is simply a matter
      of documenting those functions/classes that might be useful to
      other people, and committing to keeping their function-call
      interfaces stable (or at least compatible) in new revisions.

   b) If I identify a given function or class (e.g. square root) in my
      source code as something that is to be made available, then
      other software can make calls to it.  This identification should
      not be particularly hard in the language I'm using (maybe C++ or
      Java), and can be added to an existing function without forcing
      me to rewrite anything but the declaration.

      In this case, providing a software interface involves
      documentation, compatibility, and the aforementioned
      identification of elements in the source code.

   c) By distributing my software as a shared library of core
      functionality and a separate application that provides a GUI
      interface to it, I can allow other programmers using languages
      with compatible calling conventions to make use of my code.

      In this case, providing a software interface involves
      documentation, compatibility, and changes the distribution of my
      software:  I must provide the library and program to users of
      the program, and supply header files for other developers.

   d) By making my source code freely available, I allow other
      programmers to "cut and paste" pieces of my source code.

      In this case, providing a software interface involves
      documentation, compatibility, and the release of source
      (hopefully in addition to an executable version for users).


2) To what degree are developers of GNOME software encouraged to write
   software that provides an interface for other tools as well as a
   GUI for the user?  For example, suppose I want my tool to add
   something to your gnome calendar, or to use gimp to transform an
   image, and I want to make use of the "internal" functionality of
   these tools without having them display on the screen (I'm not
   looking for answers for these tools in particular, but just using
   them as examples).


Note that use of this "tool-making/tool-using" approach doesn't come
"for free".  While its nice to be able to use existing software tools,
it takes some care to design them in a way that provides both a
software interface and a nice human interface.  The command-line unix
tools provide both capabilities because they restrict the human
interface to several streams of characters (remember that output and
errors are separate), and this very restrictive format can be
processed by other tools without too much difficulty.

Although it isn't necessarily easy, it is possible to employ the
"tool-making/ tool-using" approach in a graphical environment -- the
old model/view/controller approach, which dates back at least 20 years
in the SmallTalk community, demonstrates this.


I apologize for wasting your time if this issue is already addressed
somewhere, but with the list discussions of "The Future of GNOME" and
the "GUI of Windows2000", I thought perhaps it was a good time to
raise this issue if it hadn't been discussed already.


Dave Wonnacott
davew@cs.haverford.edu
http://www.haverford.edu/cmsc/davew/index.html