GUI for Mma
- To: mathgroup at smc.vnet.net
- Subject: [mg7108] GUI for Mma
- From: "David Carraher" <David_Carraher at TERC.edu>
- Date: Sun, 11 May 1997 02:57:09 -0400 (EDT)
- Sender: owner-wri-mathgroup at wolfram.com
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.