MathGroup Archive 1997

[Date Index] [Thread Index] [Author Index]

Search the Archive

GUI for Mma

  • To: mathgroup at
  • Subject: [mg7108] GUI for Mma
  • From: "David Carraher" <David_Carraher at>
  • Date: Sun, 11 May 1997 02:57:09 -0400 (EDT)
  • Sender: owner-wri-mathgroup at

I would like to see Mathematica become a general purpose programming language
over the next few years.  The kernel seems extremely well suited to the task
but the graphical interface controls/components/objects, buttons, palettes,
drop-down lists, etc. will impede this shift (notwithstanding the enormous
strides in 3.0 and those envisioned for version 3.1) unless the proper steps
are take.      Several issues seem especially important:\

1. object browser:  one needs to be able to peruse and change controls such
as buttons, option boxes etc. through special purpose browsers.    Editting
the ASCII code directly (as one does after hitting shift-control-E) is
cumbersome and highly error.   Anyone who has tried to change a button
property in a sea of code knows this is far from idea.   The Options
inspector is also too inclusive.  Why should one have to wade through the
options of *everything* if is working with  an isolated control? Take a look
at Visual Basic or Delphi to see how easy it can be to inspect and change
properties.    Note, by the way, that editing via a property window does not
preclude editing the code directly.   But given the choice, 90% of
programmers will opt for the property window approach. 

2. reusable components:  Wolfram Research cannot by itself produce and
maintain all of the graphical components needed to provide broad
functionality to Mathematica.  (Not even Microsoft could do this.)   Imagine
you wish to have a Mathematica program display a database table with
automatic updating, automatic horizontal and vertical scrolling, etc.   If
the database link is changed, one wants to see the number of columns and rows
automatically change to fit the case at hand.  
Such controls already exist.   They are very complex objects, the underlying
code for which is largely irrelevant from  the typical programmer's point of
view.   Indeed, most programmers want to be shielded from all the
underpinnings of graphical controls; they only wish to alter their public
properties.   Why doesn't Mathematica allow one to use Java or Active-X
controls that conform to emerging standards?   In designing a  Web site with
Visual InterDev , one can today use a calendar control that happens to ship
with Access, even though it wasn't specifically made for the InterDev
environment.    Why should a Mathematica programmer have to spend weeks or
months of their time designing a similar control if a tried and tested
finished control already exists?

Mathematica could presumably make use of the same component were it
knowledgeable about the standards such controls use.    In this way,
Mathematica would benefit from the considerable expertise of Microsoft, Sun,
and other companies already well-versed in reusable components.

3. cell-independent windows/forms/notebooks.   For the graphical controls to
become truly flexible, programmers must be able to place them wherever they
want on forms.   This would require an alternative to cell-based visual
displays.   Normal notebooks consisting of "lists" of cells would not
necessarily be eliminated.    Perhaps the free-roaming windows would
ultimately be written as cells.  The point is they would not always have to
*look* like bunches of cells.

I would like to hear from others in the MathGroup about these issues.  
Perhaps we can all learn from discussing these points and give Wolfram
Research some feedback that can dramatically improve Mathematica and make it
more accessible to a wide range of programmers and programming tasks.

  • Prev by Date: Re OPTICA
  • Next by Date: Smoothing splines
  • Previous by thread: Re OPTICA
  • Next by thread: Re: GUI for Mma